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I.  INTRODUCTION 


A.  BACKGROUND 


The  United  States  Congress  mandated  in  the  1992  Department  of  Defense  (DOD) 
Appropriation  Act  that: 

"None  of  the  funds  appropriated  in  this  Act  may  be  used  to  fill  the  Commander’s 
position  at  any  military  medical  facility  with  a  health  care  professional  unless  the 
prospective  candidate  can  demonstrate  professional  administrative  skills.  ”  [Ref.  1] 

In  response  to  this  mandate,  the  Deputy  Surgeon  General  of  the  Navy  established  a 
partnership  between  the  Bureau  of  Medicine  and  Surgery  (BUMED)  and  the  Naval 
Postgraduate  School  (NPS)  to  develop  a  comprehensive  competency-based  educational 
program  for  the  U.  S.  Navy’s  senior  health  care  executives.  This  initiative  has  taken  the 
form  of  the  Executive  Management  Education  (EME)  Program. 


1.  What  is  EME? 

The  EME  Program  is  an  executive  medical  education  curriculum  consisting  of  49 
course  modules  and  410  hours  of  instruction.  The  syllabus  was  developed  over  an  18 
month  period  by  subject  matter  experts  at  NPS  after  a  careful  analysis  of  the  core 
competencies  required  in  the  field  of  health  care  administration.  [Ref  2]  To  date,  DOD 
has  defined  44  administrative  competencies  across  nine  competency  categories  that 
pertain  specifically  to  health  care  administration.  The  BUMED/NPS  team  started  with 
these  competencies  and  completed  a  detailed  needs  assessment  to  identify  those  skills 
which  the  Navy’s  senior  medical  officers  felt  were  most  important  to  effectively  manage 
a  military  medical  treatment  facility  (MTF).  The  current  EME  Program  curriculum  was 
built  around  the  findings  of  that  needs  assessment.  The  curriculum,  however,  is  not  static 
and  future  expansion  to  meet  the  remaining  DOD  defined  competencies  is  underway  - 
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particularly  in  regard  to  changing  business  practices  associated  with  DOD  health  care 
reform  initiatives  (TRICARE). 

The  objective,  then,  of  the  EME  Program  is  to  educate  senior  military  health  care 
executives  to  aehieve  those  specifically  defined  administrative  skills  and  competencies 
that  have  been  determined  a  prerequisite  for  command  of  major  DOD  MTFs  or  other 
complex  health  care  delivery  systems. 

Implementation  of  the  EME  curriculum  is  as  follows.  Teams  of  NPS  faculty 
members  travel  to  MTFs  around  the  world  to  provide  blocks  of  instruction  covering  the 
various  competency  categories.  Because  it  is  fiscally  and  operationally  impractical  to 
educate  all  of  the  Navy’s  prospective  health  care  leaders  in  one  central  location,  these 
presentation  teams  spend  a  considerable  amount  of  time  “on  the  road”  teaching  course 
modules  so  that  the  disruption  to  MTF  day  to  day  operations  is  minimized.  While  on-site 
delivery  of  course  modules  by  NPS  faculty  is  the  current  pedagogy,  the  future  use  of  a 
distributed  educational  system  such  as  videotele-education  (VTE)  and 
videoteleconferencing  (VTC)  is  a  viable  alternative  format  for  some  of  the  course 
modules. 


2.  Why  EMETRAK? 

As  the  program  matures,  many  offices  within  the  Department  of  the  Navy  will  be 
interested  in  the  EME  program  enrollment  status  of  selected  officers.  These  entities  will 
range  fi-om  Medical  Department  specialty  advisors,  detailers,  and  promotion  boards  to  the 
Corps  chiefs  as  they  assess  an  officer’s  specific  administrative  skills  and  qualifications 
preliminary  to  assignment  or  promotion  decisions.  Progress  towards  completion  of  the 
EME  program  will,  in  the  future,  be  viewed  as  a  commitment  to  attaining  the  necessary 
competencies  required  for  command  of  a  Navy  MTF.  For  this  very  reason,  an  accurate 
and  up-to-date  record  of  EME  course  completion  is  critical.  Moreover,  due  to  the 
comprehensive  nature  of  the  EME  program,  it  may  take  several  years  for  an  officer  to 
complete  the  entire  curriculum.  Therefore,  officers  will  move  to  new  duty  stations  and 
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serve  in  many  different  billets  while  enrolled  in  the  program.  In  spite  of  the  officer  career 
dynamics,  the  Navy  will  require  that  an  accurate  cumulative  record  of  attained 
competencies  be  maintained.  This  concept  is  the  basis  for  the  Executive  Management 
Education  Tracking  (EMETRAK)  system. 

The  EME  program  manager  located  at  the  Naval  School  of  Health  Sciences 
(NSHS)  in  Bethesda,  MD  and  the  EME  program  coordinator  at  NFS  have  indicated  that 
an  information  system  supporting  the  EME  Program  should  have  the  following 
characteristics: 

•  Provide  a  consolidated  record  of  all  eligible  Navy  medical  department  officers 
(Medical,  Medical  Service,  Nurse  and  Dental  Corps),  their  billet  and 
command  information,  and  the  specifics  of  each  course  taken  within  the  EME 
program. 

•  Officer  demographics  data  in  the  system  must  be  capable  of  being  updated  by 
the  officer’s  command  or  through  information  provided  directly  by  the  Bureau 
of  Naval  Personnel  (BUPERS). 

•  EME  course  completion  data  should  input  at  the  officer’s  command,  a  third- 
party  training  site,  by  the  EME  program  coordinator’s  staff  at  NPS,  or  by  the 
EME  program  manager’s  staff  at  the  NSHS. 

•  A  “robust”  query  and  reporting  capability  on  the  officers  enrolled  in  the  EME 
program. 

•  The  officer’s  integrated  educational  record  must  be  made  available  to  all 
personnel  agencies  providing  career  mentoring  to  medical  department  officers 
or  making  decisions  about  officer  career  planning. 

•  A  future  expansion  capability  to  enable  remote  access  and  viewing  of  officer 
records  by  responsible  agencies. 

The  characteristics  described  in  this  section  serve  as  a  starting  point  for  further 
study  of  system  requirements. 
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B.  PURPOSE  OF  RESEARCH 


The  purpose  of  this  research  is  to  conduct  a  thorough  study  of  the  information 
requirements  for  a  system  that  supports  the  EME  program  and  to  recommend  an 
implementation  plan  that  adequately  satisfies  those  needs. 


C.  METHOD 

The  Systems  Development  Life  Cycle  (SDLC)  provides  a  logical  methodology 
for  developing  and  maintaining  an  information  technology  (IT)  solution.  The  SDLC  is  a 
project  management  tool  used  to  plan,  execute,  and  control  an  IT  systems  development 
project.  SDLC  consists  of  five  phases:  Systems  Analysis,  Systems  Definition,  Systems 
Design,  Systems  Implementation,  and  Systems  Support.  [Ref.  3]  The  cycle  begins  with 
the  Systems  Analysis  phase  in  which  a  business  problem  and  an  information  architecture 
to  solve  the  business  problem  are  defined.  During  the  next  phase.  Systems  Definition,  the 
user  requirements  are  closely  analyzed  and  a  logical  design  for  information  flow  and  data 
modeling  are  proposed.  Systems  Design,  the  third  phase,  involves  the  evaluation  of 
alternative  solutions  and  the  physical  design  of  an  information  system.  The  fourth  step  is 
the  Systems  Implementation  phase  which  encompasses  the  construction  and  testing  of  the 
production  system.  The  final  phase.  Systems  Support,  involves  ongoing  maintenance  and 
recommendations  for  system  improvement.  The  SDLC  will  be  used  as  a  guide  for  the 
development  of  an  information  system  to  support  the  business  needs  of  the  EME 
program. 


D.  SCOPE  OF  RESEARCH 

The  study  will  focus  on  the  following  research  questions  in  its  examination  of 
possible  solutions  for  EMETRAK: 


1.  Who  are  the  EMETRAK  system  owners  and  users  and  what  are  their 
information  requirements? 


2.  What  type  of  information  system  will  support  the  future  needs  of  the  EME 
program? 

a.  A  single-user  personal  computer  (PC)  based  database  application? 

b.  A  multi-user  database  architecture  implemented  over  a  local  area 
network? 

c.  A  multi-user  database  architecture  implemented  over  a  wide  area 
network? 

3.  What  system  processes  are  necessary  to  track  the  administrative  educational 
records  of  all  EME  eligible  Navy  Medical  Department  officers? 


4.  Once  a  computer  solution  is  selected,  what  features  of  contemporary  database 
management  system  applications  are  desired  for  the  EMETRAK  system? 


5.  What  are  the  design  issues  for  the  candidate  system? 

a.  What  will  the  conceptual  data  model  look  like? 

b.  What  will  the  process  model  look  like? 

c.  How  will  data  be  updated? 

d.  What  type  of  architecture  will  support  the  process  and  data 


models? 

e.  What  are  the  data  and  system  security  issues? 
f  What  are  the  system  inputs  and  outputs? 

g.  What  type  of  queries  are  required? 

h.  Will  the  database  architecture  be  scaleable  and  support  future 
growth? 
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This  study  will  involve  a  detailed  examination  of  the  feasibility,  costs,  benefits, 
process  and  data  requirements  of  developing  an  operational  database  management 
system.  Requirement  specifications  for  a  prototype  database  application  will  also  be 
developed.  The  end  product  will  be  a  prototype  database  application  developed  from  the 
requirement  specifications  using  the  Microsoft  Access  2.0®  relational  database 
application.  The  study  concludes  with  recommendations  for  implementing  a  remotely 
accessed  multi-user  database  application. 


E.  THESIS  ORGANIZATION 

The  thesis  is  organized  into  seven  chapters  and  eleven  appendices.  Chapter  II 
discusses  the  Systems  Analysis  phase  and  includes  an  initial  feasibility  study  of  the 
proposed  system.  Chapters  III,  IV,  and  V  address  definition,  design  and  implementation 
issues,  respectively,  for  the  prototype  system  (Phase  1).  Chapter  VI  discusses  analysis 
and  definition  issues  for  a  multi-user  system  (Phase  II).  Lessons  learned  during  each 
phase  of  the  SDLC  are  included  in  the  appropriate  chapters.  Conclusions  and 
recommendations  are  provided  in  Chapter  VII.  Existing  system  network  topologies, 
process  models,  prototype  queries,  and  reports  are  included  as  appendices  to  the  study. 
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II.  SYSTEMS  ANALYSIS  PHASE 


A.  METHOD 

The  Systems  Analysis  phase  began  with  an  initial  investigation  of  the  business 
environment.  The  EME  program  manager,  EME  program  coordinator,  and  selected  NFS 
Systems  Management  faculty  were  interviewed  to  determine  the  project  scope  and  system 
boundaries.  A  questionnaire  (Appendix  A)  was  the  primary  tool  used  during  the  initial 
interviews  to  help  define  the  problem  and  gain  an  understanding  of  the  people,  data, 
activity,  and  networking  requirements  of  the  proposed  system.  NFS  staff  studies  and 
EME  program  documentation  were  consulted  to  provide  insight  into  the  history  and  goals 
of  the  executive  education  program.  The  EME  course  cateilog  provided  curriculum 
information  and  described  the  competency  categories.  A  problem  statement  and  system 
requirements  were  developed  from  the  information  gathered  during  the  initial 
investigation. 


B.  PROBLEM  STATEMENT 

The  EMETRAK  system  is  to  provide  an  integrated  educational  record  on  all  Navy 
medical  department  officers  in  the  grade  of  0-3  (LT)  and  above  enrolled  in  the  EME 
curriculum.  This  entails  tracking  approximately  11,300  officers  located  in  13  Health 
Service  Regions  (HSR)  around  the  world  (Figure  1)  and  officers  assigned  to  operational 
units  (ships,  deployed  units,  etc.).  The  record  must  be  made  available  to  the  officer  and 
those  personnel  agencies  responsible  for  providing  officer  career  planning  decisions 
(BUMED,  BUFERS).  The  system  must  be  flexible  enough  to  handle  a  highly  transient 
population  and  different  course  modules  from  a  variety  of  executive  education  sources 
outside  of  the  EME  curriculum.  The  long-term  requirement  for  the  system  is  for 
distributed  access  to  officer  information  from  various  sites  including  all  major  Navy 
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medical  treatment  facilities  (MTF),  regional  training  sites,  curriculum  sponsors,  BUMED, 
BUPERS,  and  the  EME  Program  staff  for  a  total  of  71  end-user  sites.  Table  1  shows  the 
number  of  anticipated  end-user  sites  for  a  distributed  system  and  Appendix  B  contains  a 
detailed  listing  of  the  MTFs  which  would  have  EMETRAK  terminals. 


Agency 

Number 

Medical  Treatment  Facilities 

55 

BUMED 

5 

BUPERS 

3 

NSHS.  Bethesda,  MD 

3 

NPS 

5 

Total 

71 

Table  1.  Proposed  Number  oi 

'End-user  Sites 

C.  SCOPE 

The  proposed  information  system  will  collect,  maintain,  collate,  and  report  all 
information  required  by  the  EME  program.  This  includes  information  gathered  by  the 
program  manager  at  the  Naval  School  of  Health  Sciences  (NSHS)  in  Bethesda,  MD,  the 
program  coordinator  at  NPS,  individual  commands,  BUPERS,  BUMED,  and  other 
external  training  sources  granting  continuing  education  unit  (CEU)  credits.  The  scope  of 
the  EMETRAK  system  will  be  limited  to  the  business  functions  of  the  EME  program 
and,  consequently,  no  effort  is  foreseen  to  consolidate  the  tracking  requirements  of  other 
professional  medical  education  programs.  However,  the  backbone  of  this  system  could 
suggest  additional  future  applications. 


12  ^ 

Figure  1.  DOD  Health  Service  Regions  [After  Ref.  4,  p.  8] 
Note:  HSR  13  refers  to  overseas  commands 


1.  System  Owner  and  Users 


a.  System  Owner 

The  initial  project  management  responsibilities  for  the  development  of  the 
proposed  information  system  has  been  assigned  to  the  EME  program  coordinator  at  NFS 
by  the  EME  program  manager  at  NSHS,  Bethesda.  The  program  coordinator  is 
considered  to  be  the  EMETRAK  system  owner  for  the  purpose  of  this  study. 


b.  System  Users 


The  information  system  will  directly  affect  the  following  users: 


•  EME  program  manager  and  the  staff  at  NSHS,  Bethesda,  MD. 

•  EME  program  support  staff  at  NFS 
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•  Staff  Education  and  Training  Departments  of  Navy  MTF  s 

•  Personnel  Departments  of  Navy  MTFs 

•  BUMED  Planning  and  Programming  Divisions 

•  Medical  Department  Specialty  Advisors 

The  information  system  will  indirectly  affect  the  following  users; 

•  Medical  Department  Corps  Chiefs  and  their  offices 

•  BUPERS 

•  All  Navy  medical  department  officers  (0-3  and  above)  in  the 
Medical,  Medical  Service,  Nurse,  and  Dental  Corps 


2.  Context  Diagram 

A  context  diagram  defines  the  boimdary  of  a  system-in-focus,  identifies  its  key 
external  entities,  and  the  interaction  between  the  two.  [Ref  5,  p.  221]  The  EMETRAK 
context  diagram  (Figure  2)  depicts  BUMED,  BUPERS,  the  MTFs,  the  Corps  chiefs, 
NSHS,  and  the  EME  program  staff  as  external  entities  to  the  internal  functionality  of  the 
EMETRAK  system-in-focus.  The  diagram  also  illustrates  the  anticipated  interactions,  in 
terms  of  inputs  and  outputs,  between  the  external  entities  and  the  EMETRAK  system. 


3.  Internal  Entities 

Internal  entities  are  objects  within  a  closed  system  about  which  the  system  owner 
desires  to  collect  data.  Within  EMETRAK,  there  are  five  major  entities:  OFFICER,  UIC, 
CLASS,  COURSE,  and  COMPETENCY. 

•  OFFICER  -  OFFICER  refers  to  any  medical  department  officer  (grade 
0-3  and  above)  with  the  designator  of  2100  (Medical  Corps),  2200  (Dental 
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Corps),  2300  (Medical  Service  Corps),  or  2900  (Nurse  Corps)  enrolled  in 
the  EME  program. 

•  UIC  -  UIC  refers  to  the  unit  identification  code  which  is  a  unique 
numerical  designation  for  a  DOD  medical  treatment  facility. 

•  CLASS  -  A  CLASS  is  an  instance  of  an  EME  eligible  officer  taking  a 
course  module. 

•  COURSE  -  A  COURSE  is  one  of  the  course  modules  designated  in  the 
EME  curriculum. 

•  COMPETENCY  -  COMPETENCY  refers  to  a  competency  category 
specified  in  the  EME  course  catalog. 


(SUMMARY  BY  COMPETENCY 
AND  CORPS) 


Figure  2.  EMETRAK  Context  Diagram 
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D.  INFORMATION  SYSTEM  FUNCTIONS 


1.  Desired  Functions 

•  Ability  to  add,  delete,  modify,  display,  and  automatically  update 
related  fields 

•  Ability  to  search  and  query  the  database  for  records  based  on  a  variety 
of  selection  criteria 

•  Ability  to  print  screens  and  reports  as  desired  by  the  users  to  satisfy 
local,  higher  echelon,  and  other  on-demand  requirements 

•  Ability  to  print  officer  transcripts  and  completion  certificates 

2.  Data  To  Be  Tracked 

•  Officer  Information  -  Social  Security  Number  (SSN),  name,  rank, 
billet  sequence  code  (BSC)  number,  designator,  job  title,  command 
unit  identification  number  (UIC)  and  electronic  mail  address 

•  Command  Information  -  UIC  number,  address,  commercial  telephone 
number.  Defense  Switched  Network  (DSN)  telephone  number,  HSR 
number 

•  Course  Information  -  Course  ID  number,  course  name,  course  length 
in  hours,  CEU  credit  hours,  competency  classification,  and  course 
sponsor 

•  Competency  Information  -  Competency  title  and  course  assigned  to 
that  competency 

•  Class  Information  -  SSN  of  the  officer,  course  ID  number,  class  date, 
class  location,  class  instructor,  and  host  command 
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3.  Queries  To  Be  Generated 


System  queries  are  divided  into  three  major  categories:  structured,  interactive,  and 
statistical  queries.  Structured  queries  are  standardized  pre-coded  queries  which  require 
no  user  input  other  than  selecting  the  actual  query.  Structured  queries  should  focus  on 
providing  a  browse  function  for  the  data  in  different  representations.  Interactive  queries 
should  be  more  flexible  and  provide  a  narrower  cross-sectional  view  of  the  data  based 
upon  the  criteria  input  by  the  user.  Statistical  queries  should  be  designed  to  provide 
statistical  and  demographic  summaries  of  the  database  for  the  purposes  of  program 
management  rather  than  for  viewing  data. 

a.  Structured  Queries 
Structured  queries  should  include: 

•  All  officers  in  alphabetical  order 

•  All  officers  sub-divided  by  command 

•  ListofallUICs 

•  List  of  all  EME  courses 

•  List  of  all  course  titles  by  competency  category 

•  List  of  all  course  modules  provided  in  the  last  30/60/90  days 

b.  Interactive  Queries 
These  should  include: 

•  All  officers  and  course  modules  competed  in  a  specified 
command  (user  inputs  LfIC) 

•  List  of  all  officers  satisfying  a  specific  profile  (user  inputs  one 
or  all  of:  rank,  HSR,  competency,  designator) 


13 


•  List  of  course  modules  and  hours  completed  by  a  specific 
officer  (user  inputs  SSN) 

c.  Statistical  Queries 

Statistical  queries  should  include: 

•  The  number  of  officers  that  have  attained  each  competency 

•  The  number  of  students  within  each  HSR  enrolled  in  EME 

•  The  percentage  of  officers  that  have  completed  each 

competency  category  within  each  UIC 

•  The  percentage  of  officers  that  have  completed  each 

competency  category,  sub-divided  by  rank 

•  The  number  of  officers  that  have  completed  each  competency 
category 

4.  Reports  To  Be  Generated 

EMETRAK  must  be  capable  of  generating  reports  based  upon  the  structured  and 
interactive  queries  that  have  been  mentioned  in  the  previous  section.  The  reports  desired 
by  the  system  owner  include  the  following: 

•  Alphabetical  roster  of  all  enrolled  officers  and  the  course  modules  that 
they  have  completed 

•  Alphabetical  roster  of  officers,  sub-divided  by  command,  and  the 
course  modules  that  each  has  completed 

•  Mailing  list  of  all  participating  commands 

•  List  of  all  EME  course  modules  by  competency  category 

•  Course  completion  letters 


14 


•  Course  completion  certificates 

•  Officer  transcripts 


E.  PROJECT  PHASES 

The  proposed  system  is  straight-forward  in  its  business  rules,  logical  architecture, 
input/output  and  report  generation  requirements.  What  sets  it  apart  is  the  system  owner’s 
desire  to  implement  a  low  cost  interactive  system  distributed  over  a  wide  area.  Further, 
the  system  owner  desires  an  initial  data  storage,  information  retrieval,  and  reporting 
capability  within  60  days  of  project  commencement  because  of  the  frequency  with  which 
courses  will  be  delivered  during  the  last  quarter  of  FY-95.  These  requirements  lend 
themselves  to  a  two-phased  approach  for  system  development.  Phase  I  is  envisioned  as  a 
single-user  personal  computer  (PC)  based  database  application  developed  using  a  fourth 
generation  language  (4GL)  and  rapid  prototyping  techniques.  Phase  II  migrates  all 
functionality  of  the  single-user  system  to  a  widely  distributed  multi-user  environment 
using  the  existing  Navy  Medical  Department  Network  (NMDN)  as  a  backbone. 


F.  FEASIBILITY 

The  feasibility  analysis  is  a  cross  life  cycle  activity  that  must  be  continuously 
performed  throughout  the  systems  development  process.  [Ref.  5,  p.  812]  The  initial 
assessment  is  performed  to  measure  the  urgency  of  the  problem  and  determine  if  further 
detailed  study  of  the  problem  is  warranted.  A  more  detailed  study  of  the  problem,  its 
opportunities,  and  constraints  is  completed  during  the  Systems  Analysis  phase  of  the 
SDLC  and  will  be  discussed  in  the  next  chapter.  The  feasibility  analysis  is  guided  by  the 
following  tests:  political,  operational,  economic,  technical,  and  schedule  feasibility. 
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1. 


Political  Feasibility 


It  is  clear  from  the  congressional  mandate  that  today’s  taxpayer  has  the  same 
expectation  of  health  care  administration  in  the  Defense  Department,  with  respect  to 
quality  and  cost  containment,  as  they  do  of  the  private  sector.  These  expectations  lead  to 
a  new  era  in  which  DOD  must  better  prepare  its  medical  leadership  for  the  future 
challenges  of  health  care  management.  This  new  climate  of  educating  the  prospective 
commanders  in  speeific  health  care  related  administrative  skills  and  competencies 
formalizes  what  has,  in  the  past,  been  an  informal  process  left  to  the  individual  medical 
department  officer.  As  with  any  change  effort,  the  idea  of  having  a  formal  requirement 
for  executive  education  will  undoubtedly  meet  some  initial  resistance.  However,  since 
the  Surgeon  General  of  the  Navy  has  given  strong  support  to  the  EME  concept  and  there 
are  strong  budgetary  implications  associated  with  the  successful  implementation  of  such  a 
program.  Navy-wide  acceptance  is  all  but  assured.  Language  in  the  DOD  Authorization 
Act  for  FY-96  further  directs  executive  education  activities  in  support  of  TRICARE 
program  implementation  -  both  for  Lead  Agent  commanders  and  their  HSR  MTF  support 
personnel.  [Refs.  6, 7] 

The  EME  program  management  staff  views  the  current  climate  as  an  opportunity 
to  provide  quality,  cost  effective  executive  education  not  only  to  those  prospective  MTF 
commanders,  but  also  to  the  larger  population  of  medical  officers  thereby  increasing  the 
overall  competency  of  the  Navy’s  medical  professionals.  An  effective  information 
system,  with  the  capabilities  envisioned  for  EMETRAK,  that  captures  the 
accomplishments  of  program  participants  and  directly  involves  them  in  their  educational 
process  will  accelerate  initial  acceptance  of  the  EME  program  ■within  the  Navy’s  medical 
community. 
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2.  Operational  Feasibility 


Operational  feasibility  is  a  measure  of  how  well  a  solution  to  a  problem  will  work 
in  an  organization.  This  section  examines  the  anticipated  level  of  acceptance  of  an 
automated  solution  for  the  EME  program. 

The  program  manager  anticipates  that  during  the  final  quarter  of  FY-95  65  hours 
of  formal  instruction  will  be  provided  and  270  officers  will  be  enrolled  in  the  program. 
That  number  is  expected  to  triple  during  FY-96  and  will  steadily  increase  over  the  next 
several  years.  Clearly,  automating  the  process  of  recording  instances  of  EME  instruction, 
producing  program  reports,  and  officer  transcripts  is  justified  given  the  anticipated 
frequency  of  course  delivery  and  volume  of  data  in  the  future. 

Implementation  of  any  new  information  system  presents  operational  challenges. 
While  the  routine  recording  of  basic  officer  information,  course  modules,  and  class 
rosters  at  the  EME  program  office  will  offer  no  serious  challenges,  the  periodic  import  of 
officer  personnel  information  from  the  BUPERS  database,  the  regular  distribution  of 
program  information  to  the  various  customer  sites,  and  remote  access  to  the  database  over 
a  wide  area  network  (WAN)  by  those  customer  sites  is  a  bit  more  difficult.  For  these 
reasons,  separating  the  functional  design  of  Phase  I  from  the  challenges  of  remote  access 
in  Phase  II  are  necessary. 


a.  Data  Import 

The  officers  who  participate  in  the  EME  program  are  highly  transient. 
They  can  expect  to  move  to  a  new  duty  station  a  minimum  of  every  three  years. 
Therefore,  the  officer  data  file  in  the  EMETRAK  database  will  require  frequent  updating 
in  order  to  maintain  data  accuracy.  In  order  to  accomplish  this  requirement,  the  Officer 
Master  file  from  BUPERS  could  be  used  as  a  source  to  update  EMETRAK  officer 
information.  The  frequency  of  update  is  anticipated  to  be  a  monthly  requirement  and  an 
agreement  between  the  EME  program  staff  and  BUPERS  for  the  recurring  download  of 
medical  department  officer  data  is  being  coordinated. 
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b.  Remote  Access 

Navy  Medicine  maintains  a  three-tiered  hierarchical  network  infrastructure 
known  as  the  Navy  Medical  Department  Network  (NMDN).  The  NMDN  is  composed  of 
a  wide  area  network  (WAN),  a  series  of  metropolitan  area  networks  (MAN)  and  local 
area  networks  (LAN).  The  WAN  uses  the  existing  Defense  Information  Systems  Network 
(DISN),  formerly  known  as  the  Defense  Data  Network  (DDN),  a  packet  switched 
network  conforming  to  the  Consultative  Committee  for  International  Telegraphy  and 
Telephony  (CCITT)  X.25  protocol  to  provide  connectivity  between  each  MAN.  The 
MANS  are  centered  around  major  regional  medical  installations.  Within  each  MAN  are 
interconnected  Ethernet  local  area  networks  (LANs)  which  conform  to  IEEE  802.3 
standards  and  support  local  MTF  operations.  Remote  access  to  EME  program 
information  is  feasible  in  Phase  I  through  plain  old  telephone  service  (POTS),  facsimile, 
electronic  mail,  electronic  file  transfer,  and  World  Wide  Web  (WWW)  access.  A  study 
of  the  existing  NMDN  topologies  reveals  that  in  a  Phase  II  implementation  the  remote 
access  options  to  EMETRAK  data  include:  dial-in  access  using  a  modem,  WWW 
applications,  and  the  use  of  client-server  applications  over  DISN. 


c.  User  Acceptance 

Observation  of  the  EME  Management  Group  during  their  normal  office 
routine  reveals  that  they  are  intelligent  and  literate  personal  computer  users.  They  are 
familiar  with  the  Windows®  operating  environment  and  Windows-compatible 
applications.  The  selection  of  a  commercial-off-the-shelf  (COTS)  Windows-compatible 
database  application  seems  a  preferable  solution  for  Phase  I  because  of  the  familiarity  of 
the  EME  support  staff  with  the  Windows®  graphical  user  interface  and  its  fimctionality. 
Familiarity  with  the  application  environment  and  confidence  in  its  interoperability  with 
other  EME  program  office  applications  will  enhance  end-user  acceptance  of  any  software 
solution  provided  as  part  of  Phase  I. 
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The  hope  for  Phase  II  is  to  migrate  the  functionality  of  the  Phase  I  single-user 
application  to  a  multi-user  environment  with  an  EMETRAK  application  interface 
residing  at  each  MTF  and  other  sites  exercising  managerial  responsibility  for  the 
program.  Acceptance  of  an  EMETRAK  application  by  this  larger  end-user  population 
will  require  that  the  application  be  compatible  with  other  MTF  software  applications, 
have  a  familiar  graphical  user  interface,  and  have  acceptable  response  time  over  the 
network.  A  survey  of  Navy  MTF  office  automation  products  shows  that  the  Windows® 
version  of  Microsoft  Office  Professional  4.3  is  the  office  automation  standard.  This 
integrated  package  provides  Microsoft  Word  6.0®  for  word  processing.  Excel  5.0®  for 
spread  sheet  functions,  Powerpoint  4.0®  for  presentations,  and  Access  2.0®  for  database 
functions.  A  Windows®  application  which  is  compatible  with  the  current  integrated  suite 
standard  or  uses  one  of  its  resident  applications  will  certainly  enhance  acceptance  of  the 
Phase  II  product. 


3.  Economic  Feasibility 

A  separate  cost-benefit  analysis  was  completed  to  measure  the  cost  effectiveness 
of  the  project  and  portions  of  that  analysis  are  provided  in  this  section  to  show  the 
relative  merits  of  the  proposed  options.  [Ref  8] 


a.  Costs 

The  options  considered  were  1)  a  completely  manual  system,  2)  a  single 
user  database  management  system  (DBMS)  with  manual  input/output/information 
exchange  which  represents  Phase  I  functionality,  and  3)  a  multi-user  DBMS  with 
distributed  access  via  the  Internet  which  represents  Phase  II  functionality.  The  analysis 
began  by  identifying  the  tasks  required  to  successfully  implement  a  mamial  record¬ 
keeping  and  tracking  system  for  the  program.  These  tasks  were  measured  in  person- 
hours  and  the  manual  system  was  then  used  as  a  baseline  from  which  to  compare  the 
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relative  costs  of  two  automated  solutions.  Standard  government  wage  rates  provided  by 
the  NPS  Human  Resource  Office  and  adjusted  by  the  requirements  of  the  Navy 
Comptroller’s  manual  were  used  for  calculating  personnel  costs  for  each  alternative.  The 
cost  of  each  alternative  was  sub-divided  into  non-recurring  costs  which  considered 
activation  or  start-up  costs  and  recurring  or  operating  costs.  The  total  cost  of  each 
alternative  was  then  discounted  at  the  government  standard  rate  of  ten  percent  for  a 
period  of  seven  years  to  achieve  a  present  value  figure  which  could  be  compared. 

Project  size,  development  time,  and  average  staff  size  requirements  for  the 
development  of  the  applications  in  Alternatives  two  and  three  were  estimated  using 
Function  Point  analysis  and  the  Constructive  Cost  Model  (COCOMO)  in  the  organic  and 
semi-detached  modes,  respectively.  According  to  the  models,  the  single  user  system 
(Alternative  2  -  Phase  I)  was  a  2100  lines  of  code  project  which  could  be  developed  in 
5.23  person-months  with  an  average  staff  size  of  1.33  persons.  The  models  estimated  that 
the  multi-user  system  (Alternative  3  -  Phase  II),  a  slightly  more  complex  project  with 
over  3130  lines  of  code,  could  be  completed  with  an  average  staff  size  of  1.88  persons  in 
5.75  months.  These  figures  were  the  basis  for  the  non-recurring  project  development  cost 
calculations  after  standard  wage  rates  were  applied. 

Tables  2  through  4  summarize  the  present  value  costs  of  the  three 
alternatives  discussed  in  the  cost-benefit  analysis.  The  cash  flow  figures  in  the  tables 
include  both  non-recurring  and  recurring  costs.  From  the  tables  it  is  apparent  that  the 
manual  system  (Alternative  1)  is  the  most  expensive  option  in  terms  of  present  value. 
The  reason  for  this  higher  figure  is  the  increased  aimual  operating  cost  incurred  because 
the  manually  intensive  system  requires  more  person-hours  to  maintain  a  given  set  of 
records  than  do  the  other  two  options. 

The  single  user  system  (Table  3)  reflects  a  higher  initial  investment  in 
Year  0  than  does  Alternative  1  because  this  option  requires  hardware  and  software,  but 
the  annual  operating  costs  as  a  result  of  implementing  the  system  are  projected  to  be 
significantly  less  than  the  manual  system. 
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Year 

0 

1 

2 

3 

4  5 

6 

7 

Cash  Flow 

$  32,301 

$  130,248 

$  130,248 

$  130,248 

$  130,248  $130,248 

$  130,248 

$  130,248 

PV  Factor 

1.0 

0.909 

0.826 

0.751 

0.683  0.621 

0.564 

0.513 

Present  Value 

$  32,301 

$  118,407 

$  107,642 

$  97,857 

$  88,961  $  80,873 

$  73,521 

$  66,837 

Total  PV 

$  666,400 

Table  2.  Present  Value  of  Alternative  1  Costs 


Year 

0 

1 

2 

3 

4 

5 

6 

7 

Cash  Flow 

$71,702 

$  67,074 

$  67,074 

$  67,074 

$  67,074 

$  67,074 

$  67,074 

$  67,074 

PV  Factor 

1.0 

0.909 

0.826 

0.751 

0.683 

0.621 

0.564 

0.513 

Present  Value 

$71,702 

$  60,976 

$  55,433 

$  50,393 

$45,812 

$41,647 

$  37,861 

$34,419 

Total  PV 

$  398,242 

Table  3.  Present  Value  of  Alternative  2  Costs 


Alternative  3  requires  an  even  higher  initial  investment  than  does 
Alternative  2  because  of  higher  development  costs  and  increased  complexity  with  respect 
to  operating  system,  application  software,  and  hardware  requirements.  The  annual 
operating  costs  are  also  anticipated  to  be  higher  than  Alternative  2,  however,  they  are  still 
much  less  than  Alternative  1 . 


Year 

0 

1 

2 

3 

4 

5 

6 

7 

Cash  Flow 

$  157,660 

$  80,238 

$  80,238 

$  80,238 

$  80,238 

$  80,238 

$  80,238 

$  80,238 

PV  Factor 

1.0 

0.909 

0.826 

0.751 

0.683 

0.621 

0,564 

0.513 

Present  Value 

$  157,660 

$  72,943 

$66,312 

$  60,284 

$  54,803 

$  49,821 

$  45,292 

$41,174 

Total  PV 

$  548,288 

Table  4.  Present  Value  of  Alternative  3  Costs 


b.  Benefits 


It  has  been  assumed  that  all  three  alternatives  will  accomplish  the 
mandated  requirements  of  EME.  The  tangible  benefits  of  each  alternative  are  achieved 
by  performing  the  same  job  at  a  lower  net  present  cost  than  the  other  competing 
alternatives.  A  niimber  of  intangible  benefits  can  be  identified  that  are  independent  of  the 
direct  requirement.  The  value  of  these  “intangibles”  should  be  weighed  by  the  system 
owner  in  addition  to  the  strict  bottom  line  cost. 

Both  the  single-user  and  multi-user  systems  offer  increased  manageability 
of  data  to  the  EME  program  staff  because  electronic  files  are  easier  to  maintain, 
duplicate,  and  transfer  than  paper  ones.  Further,  both  systems  offer  an  adaptable  query 
and  reporting  capability  which  is  not  available  in  a  manual  system.  There  is  intangible 
value  in  the  speed  of  information  processing  and  reduced  wait  time  for  the  customer 
provided  by  these  options.  Finally,  through  automation,  the  EME  program  would  realize 
increased  data  accuracy  and  ease  of  verification  by  using  exception  reports,  traditional 
automated  database  functions,  and  by  involving  the  officer  more  closely  with  their 
educational  record  (Figure  3). 


Information  is  accurate  and  accessible  so 
owner  incorporates  it  into  decisionmaking 


EMETRAK  infor¬ 
mation  is  more 
accurate 


Officers  take  ownership  of  their 
own  data  and  actively  participate 


Figure  3.  Data  Verification  Process 
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The  multi-user  system  offers  additional  intangible  benefits  over  each  of 
the  other  alternatives.  The  first  of  these  benefits  is  the  increased  speed  of  response  to 
customer  updates,  queries,  and  reports.  By  distributing  the  application  and  moving  many 
of  the  system  functions  out  of  a  central  program  office  and  closer  to  the  customer, 
response  time  for  information  should  dramatically  decrease.  Moreover,  the  availability  of 
program  information  should  not  be  limited  to  the  business  hours  of  the  EME  program 
office.  With  an  on-line  system  such  as  that  envisioned  in  Alternative  3,  customers  could 
simultaneously  access  the  system  24  hours  a  day.  Finally,  a  distributed  multi-user  system 
would  also  allow  the  data  entry  function  to  be  moved  closer  to  the  input  source  at  the 
MTF,  thereby  increasing  data  accuracy  and  reducing  data  entry  delays. 


c.  Cost-Benefit  Analysis  Conclusions 

The  objective  of  the  economic  feasibility  analysis  was  to  examine  the 
costs  and  benefits  associated  with  the  development  of  an  information  system.  Three 
alternatives  were  examined  and  the  present  value  costs  of  satisfying  a  given  set  of 
requirements  are  summarized  in  Table  5. 


Alternative 

System 

PV  Cost 

1 

Manual 

$666,400 

2 

Single-user  DBMS 

$398,242 

3 

Multi-user  DBMS  with  distributed  I/O 

$548,288 

Table  5.  Present  Value  Cost  Summary 


Alternative  2  is  the  least  cost  solution  and  it  should  be  selected  if  tangible 
benefits  are  the  major  evaluation  factor  and  if  the  project  continues  to  match  the 
assumptions  stated  in  the  cost-benefit  analysis.  Alternative  3  provides  a  number  of 
intangible  benefits  which  could  be  benefit  the  EME  program.  If  the  value  of  these 
intangibles  to  the  EME  program  is  greater  than  $150,046  (or  the  difference  between 
Alternatives  2  and  3),  then  Alternative  3  should  be  selected. 
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Alternative  3  costs  appear  to  exhibit  economies  of  scale  if  the  scope  of  the 
EME  program  expands  significantly.  This  does  not  appear  to  be  the  case  for  Alternatives 
1  and  2,  as  their  marginal  costs  will  quickly  begin  to  rise  if  the  program  continues  to 
expand.  Therefore,  if  the  EME  Program  expands  its  officer  base  or  is  adopted  as  a  DOD- 
wide  program,  then  Alternative  3  should  be  seriously  considered.  If  this  situation 
develops  and  a  phased  implementation  strategy  is  adopted.  Alternative  2  would  provide 
an  excellent  migration  path  to  the  multi-user  distributed  application. 


4.  Technical  Feasibility 

A  single  user  application  developed  using  a  fourth  generation  language  (4GL), 
which  closely  involves  the  end-users,  and  which  employs  rapid  prototyping  techniques 
does  not  pose  significant  technical  risk.  Technical  feasibility,  however,  is  clearly  the 
focus  risk  factor  in  Phase  II  of  the  project.  Remote  multi-user  database  operations  have 
been  performed  within  the  MANs  and  LANs  of  Navy  Medicine  for  several  years  but,  to 
date,  they  have  possessed  only  crude  user  and  graphical  interfaces.  Operating  a  client- 
server  database  management  system  across  a  WAN  using  the  Internet  is  still  a  serious 
technical  challenge. 

Although  the  Phase  I  system  will  not  use  telecommunications  links  between  sites 
to  access  system  data,  the  infi-astructure  known  as  Medical  Open  Architecture  (MED-OA) 
is  in  place  for  future  development  of  an  on-line  system.  The  chief  benefit  of  the  MED- 
OA  initiative,  which  was  begun  several  years  ago,  was  the  standardization  of  hardware, 
network  architectures,  and  applications  throughout  Navy  Medicine.  MED-OA  provided 
the  means  through  which  all  Navy  MTFs  could  have  connectivity  via  electronic  mail  and 
the  Internet.  The  MED-OA  infrastructure  now  primarily  supports  the  functionality  of  the 
Composite  Health  Care  System  (CHCS),  which  is  the  DOD-wide  patient  scheduling  and 
appointment  system,  but  it  can  serve  as  a  medium  for  a  number  of  other  applications. 

The  on-line  system  envisioned  in  Phase  II  would  not  require  heavy  transaction 
processing.  Data  throughput  requirements,  therefore,  are  anticipated  to  be  low  and  a 
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major  technical  hurdle  could  be  overcome  by  using  MED-OA  and  the  NMDN  backbone 
for  data  commimications.  The  NMDN  WAN  cormects  regional  MANs  through  relatively 
small  capacity  56  kilobits  per  second  (kbps)  digital  connections  (Figure  4).  Internal 
connectivity  between  the  hospitals  and  clinics  within  a  metropolitan  area  is  more  robust 
with  T-1  connections  and  the  availability  of  DS-1  data  rates  (1.54  megabits  per  second  - 
Mbps).  Some  MANs  even  have  Fiber  Distributed  Data  Interface  (FDDI)  connections 
with  100  Mbps  data  rates  available  between  several  of  the  medical  facilities  within  that 
regional  area. 

Detailed  MAN  topologies  were  provided  by  the  Navy  Medical  Information 
Management  Center  (NMIMC)  and  are  included  in  Appendix  C.  The  individual  MTF 
LAN  architectures  were  standardized  under  the  MED-OA  initiative  and  are  Ethernet 
networks  with  Carrier  Sense  Multiple  Access/  Collision  Detection  (CSMA/CD)  access 
methods  and  10  Base  T  unshielded  twisted  pair  (UTP)  wiring  which  support  10  Mbps 


Figure  4.  Navy  Medical  Department  Network 
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data  rates.  The  MTF  LANs  are  connected  to  regional  MAN  hubs  and  DISN  through 
Cisco®  routers  (Figure  5). 


802.3  ETHERNET  ARCHITECTURE 


CSMA/CD 


Figure  5.  Navy  MTF  Local  Area  Network  Topology 


The  primary  concern  with  using  the  existing  NMDN  backbone  to  support 
EMETRAK  is  the  limited  bandwidth  provided  by  the  DISN  56  kbps  connections  which 
provide  connectivity  between  the  MANs.  These  links  must  support  a  number  of  other 
medical  applications  and  will  inevitably  become  bandwidth  limited  as  WAN  traffic 
increases  in  the  future.  Technically  feasible  alternatives  to  using  the  current  NMDN 
include  use  of  dedicated  Integrated  Services  Digital  Network  (ISDN)  connections  to 
some  EME  customer  sites  or  dial  up  access  via  modem. 
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5. 


Schedule  Feasibility 


Implementation  of  the  EME  program  curriculum  begins  within  60  days  of  project 
commencement,  therefore  the  use  rapid  prototyping  techniques  will  ensure  that  a  Phase  I 
prototype  application  achieves  an  initial  operational  capability  before  the  end  of  FY-95  as 
specified  by  the  system  owner.  The  long-term  requirement  for  Phase  II  is  not  as  schedule 
constrained  and  will  allow  a  more  detailed  examination  of  the  critical  issues  such  as 
bandwidth  and  connectivity  requirements,  security  concerns,  and  interoperability  with 
other  DOD  and  Navy  systems.  Development  of  a  Phase  II  system  can  be  achieved  by  the 
end  of  the  third  quarter  of  FY-96.  This  allows  two  months  for  system  design,  four  months 
for  system  development,  two  months  for  testing,  and  one  month  for  distribution  and 
installation. 


G.  LESSONS  LEARNED  DURING  THE  SYSTEMS  ANALYSIS  PHASE 

1.  Requirements  Review 

Systems  analysts  and  programmers  are  fearful  of  changing  requirements.  Change, 
however,  is  the  only  constant  in  the  systems  development  process  and  IT  professionals 
continue  to  deal  with  changing  requirements  in  every  project.  Customers  frequently 
reassess  their  requirements  as  a  result  of  the  questions  and  issues  raised  by  the  analyst 
during  the  detailed  investigation  of  the  business  processes.  Usually  an  agreement 
between  the  system  owner  and  systems  analyst  is  reached  before  the  requirement  is 
finalized  and  a  specification  is  developed.  If  agreement  is  not  reached  then  requirements 
are  likely  to  change  during  the  course  of  systems  development. 

One  such  issue  arises  in  the  Systems  Analysis  phase  of  the  EMETRAK  project. 
The  system  owner  desires  a  statistical  reporting  capability  for  competencies  attained  by 
officers  enrolled  in  the  program.  This  presents  a  problem  for  the  analyst  because  the 
curriculum  is  still  under  development  and  the  EME  Program  Management  Group  is 
having  difficulty  determining  which  courses  are  required  to  complete  a  specific 
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competency  at  this  stage  of  curriculum  development.  In  the  absence  of  defined  criteria 
for  competency  definition,  the  measurement  of  completed  competencies  and  statistical 
analysis  of  the  data  are  impossible.  The  competency  issue  is  a  difficult  one  and  remains 
unresolved  at  the  conclusion  of  the  Systems  Analysis  phase.  Although  a  problem  exists 
with  the  requirement  for  statistical  reporting  at  this  stage,  delays  in  the  development  of  a 
prototype  are  not  anticipated.  The  completed  competency  issue  is  an  example  of  a 
business  rule  problem  which  should  be  addressed  by  EME  Program  Management  Group 
if  the  requirement  for  statistical  reporting  is  to  be  incorporated  into  the  production  version 
ofEMETRAK. 

The  lesson  learned  from  this  example  is  that  it  is  the  analyst’s  responsibility  to 
determine  which  issues  are  business  problems  and  which  can  be  solved  through  the 
implementation  of  technology.  The  analyst  must  recognize  the  distinction  between 
business  and  technology  issues  and  commimicate  those  to  the  system  owner.  If  the  owner 
and  analyst  fi-equently  review  the  requirements  at  this  phase  of  the  SDLC,  then  problem 
areas  can  be  identified  and  changes  to  system  requirements  can  be  incorporated  with  little 
expense  or  delay.  Changes  to  the  system  requirements  which  occur  in  later  phases  of  a 
project  are  more  costly  to  implement  and  can  delay  fielding  of  the  production  system. 


2.  Life  Cycle  versus  Bottom-Line  Costs 

A  considerable  body  of  literature  exists  which  addresses  the  subject  of  identifying 
total  life  cycle  costs  in  a  cost-benefit  analysis  for  IT  systems  development.  While  this 
method  captures  the  true  cost  of  a  system  over  its  life  cycle,  it  is  not  always  understood  or 
even  used  as  a  practical  estimate  for  DOD  program  managers  who  deal  in  real  dollars  and 
whose  programs  are  judged  by  their  price  tags  in  the  current  year.  While  the  cost-benefit 
analysis  for  this  project  looks  at  the  total  projected  life  cycle  costs  discounted  over  seven 
years,  the  program  manager  is  more  concerned  with  the  straight  bottom  line  costs  of  the 
system  hardware  and  software  as  they  relate  to  the  annual  program  budget. 
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3. 


System  Owner-Systems  Analyst  Relationship 


A  strong  relationship  is  required  between  the  system  owner  and  the  systems 
analyst  in  order  to  complete  a  successful  development  effort.  The  quality  of  that 
relationship  can  not  be  overemphasized;  it  must  be  based  on  mutual  trust  and  credibility. 

The  owner  relies  on  the  analyst  to  provide  a  technical  solution  which  solves  a 
particular  problem  and,  often  times,  must  meet  strict  operational,  economic,  and  schedule 
constraints.  This  situation  requires  that  the  system  owner  trust  the  analyst  because  every 
facet  of  the  owner’s  business  environment  and  organizational  processes  will  be  exposed 
to  investigation  and  analysis  during  the  development  of  the  IT  system.  The  analyst,  in 
turn,  trusts  the  owner  to  establish  an  atmosphere  where  free  access  to  the  organization’s 
people  and  resources  are  possible  in  order  to  complete  a  thorough  study  of  the 
environment. 

Establishing  credibility  with  the  system  owner  at  an  early  stage  of  the 
development  process  is  another  important  consideration.  Political  support  may  be 
required  when  dealing  with  difficult  internal  organizational  issues  or  policies  and  having 
credibility  with  the  system  owner  makes  the  job  of  getting  political  support  a  little  easier. 
This  type  of  support  may  be  particularly  crucial  when  process  improvement  is  required 
within  the  organization  rather  than  attempting  to  automate  a  flawed  business  process. 

The  rapport  between  the  EME  Program  Management  Group  and  system  analysts 
during  the  Systems  Analysis  phase  of  this  project  has  been  outstanding.  The  system 
owner’s  support  and  interest  enabled  a  thorough  study  of  the  business  environment  and 
system  requirements,  allowing  the  EMETRAK  project  to  move  forward  without  delay. 


29 


30 


III.  SYSTEMS  DEFINITION  PHASE 


A.  METHOD 

The  purpose  of  the  Systems  Definition  phase  is  to  define  the  business  rules  and 
requirements  of  the  proposed  system  without  consideration  of  a  specific  technology  or 
implementation.  This  is  accomplished  by  translating  the  user-identified  capabilities  into 
implementation-independent  models  that  describe  desired  system  functionality. 
Implementation-independent  models  reduce  the  risk  that  functional  requirements  will  be 
missed  during  systems  design  because  of  preoccupation  with  technical  details.  [Ref.  5,  p. 
305]  Two  types  of  conceptual  modeling  techniques  are  used  to  describe  the  proposed 
system:  process  and  data  models. 


B.  THE  CURRENT  ENVIRONMENT 

Administration  of  the  EME  program  is  characterized  by  manually  intensive 
processes.  Scheduling,  coordination,  and  confirmation  of  classes  is  conducted  through 
postal  mail,  electronic  mail,  telephone  conversations,  or  via  facsimile  transmissions. 
Class  attendance  is  recorded  on  hand-written  rosters  circulated  by  the  instructor  at  the 
course  delivery  sites.  Instructors  deliver  class  rosters  and  course  evaluations  to  the  EME 
program  office  for  processing  by  the  administrative  staff  upon  returning  from  a  teaching 
assignment. 

The  EME  administrative  staff  have  access  to  and  use  office  automation 
applications  for  routine  word  processing,  presentation  graphics,  and  limited  spread  sheet 
functions.  Course  completion  letters  and  certificates  are  generated  by  word  processing 
application  several  days  after  class  rosters  are  delivered  to  the  program  office.  Once 
course  completion  letters  and  certificates  have  been  processed  they  are  mailed  to  an 
officer’s  command.  Verification  of  officer  data  is  accomplished  through  feedback  fi-om 
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the  individual  officer  via  electronic  mail,  telephone,  or  facsimile.  Results  from  course 
evaluations  are  collated  and  entered  into  a  spread  sheet  application  for  further  analysis  by 
the  EME  program  management  group.  Paper  copies  of  all  class  rosters,  completion 
letters,  certificates,  and  course  evaluations  are  stored  at  the  NPS  program  office. 

Program  data  is  not  recorded  in  a  single  application  or  stored  in  a  central  location, 
therefore,  information  is  not  easily  retrievable.  This  situation  adversely  impacts  the 
reporting  capability  of  the  system.  Reports  are  ad  hoc  and  manually  generated  from  data 
appearing  on  class  rosters,  spread  sheet  print-outs,  or  internal  memoranda  which  is  very 
time  consuming. 

The  primary  challenges  in  the  current  system  are  timely  data  collection,  data 
verification,  and  information  retrieval.  The  scope  in  the  proposed  system,  therefore,  must 
incorporate  the  stakeholders,  namely  the  officers  themselves,  in  the  information  process 
at  the  MTF  level.  It  must  also  be  capable  of  supplying  the  EME  staff  at  NPS,  the  EME 
program  manager  at  NSHS,  BUMED,  and  the  Medical  Department  Corps  Chiefs  with 
information  to  successfully  manage  the  EME  program.  Finally,  the  new  system  must 
include  BUPERS  in  its  scope  for  importing  basic  officer  information  to  overcome  current 
data  accuracy  and  data  verification  problems. 


C.  THE  PROCESS  MODEL 

Process  modeling  is  a  technique  for  organizing  and  documenting  a  system’s 
business  processes,  inputs,  outputs,  and  data  stores.  The  process  model  consists  of 
decomposition  and  data  flow  diagrams.  [Ref.  5,  p.  350] 


1.  Decomposition  Diagrams 

Decomposition  diagrams  graphically  portray  the  user  requirements  in  terms  of 
system  functions  and  processes.  They  serve  as  a  blue  print  for  the  structure  of  the  system 
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from  which  data  flows  are  modeled.  The  EMETRAK  decomposition  diagrams  have  three 
levels  (zero,  one,  and  two)  that  identify  key  system  processes. 

a.  Level  Zero 

The  level  zero  or  overview  decomposition  diagram  (Figure  6)  depicts  three 
subsystems:  data  maintenance  (process  PI),  analysis  (process  P2),  and  reports  (process 
P3). 


Figure  6.  Level  Zero  Decomposition  Diagram 


b.  Level  One 

Level  one  diagrams  decompose  each  subsystem  into  subordinate 
processes.  These  processes  correspond  to  the  information  system  functions  specified  in 
the  previous  chapter.  Subordinate  processes  which  have  pound  signs  (#)  next  to  the 
process  number  indicate  the  lowest  level  logical  function. 

Processes  P  1.1  through  P  1.5  (Figure  7)  conform  to  the  functions  required 
to  collect,  maintain,  and  manage  data  identified  by  the  system  owner  during  the  analysis 
phase. 
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Figure  7.  Level  One  Process  One  Decomposition  Diagram 


Processes  P  2.1#  through  P  2.3#  (Figure  8)  reflect  the  three  general  types 
of  queries  identified  in  the  information  system  functions  section  of  the  previous  chapter: 
structured,  interactive,  and  statistical. 


Figure  8.  Level  One  Process  Two  Decomposition  Diagram 

Processes  P  3.1#  through  P  3.3#  (Figure  9)  identify  the  general  categories 
of  reports  requested  by  the  program  manager.  Reports  are  closely  related  to  system 
queries,  however,  they  are  modeled  as  distinctly  different  logical  processes  during 
systems  definition. 
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Figure  9.  Level  One  Process  Three  Decomposition  Diagram 


c.  Level  Two 

The  level  two  diagrams  (Figure  10)  depict  the  lowest  level  logical 
functions  of  the  proposed  system.  The  Update  Officer  Information  process  (P  1.1)  is 
decomposed  into  the  add  officer,  modify  officer  information,  delete  officer,  and  change 
location  sub-processes  (P  1.1.1#  through  P  1.1.4#).  Update  Course  Information  (P  1.2) 
decomposes  into  the  add  course,  modify  course  information,  and  assign  course  to 
competency  sub-processes  (P  1.2.1#  through  P  1.2.3#).  Update  Command  Information  (P 
1.3)  is  comprised  of  the  add  command,  modify  command  information,  and  delete 
command  sub-processes  (P  1.3.1#  through  P  1.3.3#).  Generate  Class  Information  (P  1.4) 
contains  the  add  class  and  modify  class  information  sub-processes  (P  1.4.1#  through 
1.4.2#).  The  last  level  two  process,  Import/Export  Information  (P  1.5),  consists  of  the 
create  backup,  import  SUPERS  data,  database  file  import,  and  database  file  export  sub¬ 
processes  (P  1.5.1#  through  1.5.4#). 
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Figure  10.  Level  Two  Decomposition  Diagrams 


2.  Data  Flow  Diagrams 

Data  flow  diagrams  (DFD)  model  the  flow  of  data  through  a  system’s  essential 
processes.  They  combine  information  from  both  the  context  and  decomposition  diagrams 
into  a  series  of  charts  showing  entity,  data,  and  process  interactions.  Recall  that  a  context 
diagram  identifies  which  external  entities  interact  with  the  system  and  decomposition 
diagrams  identify  the  essential  system  processes.  In  a  DFD,  data  is  input  by  external 
entities,  transformed  by  system  processes,  and  output  to  other  external  entities.  The 
convention  followed  is  the  Gane  and  Sarson  symbol  set  which  uses  processes,  data  flows, 
internal  or  external  entities,  and  data  stores  [Ref  5,  pp.  350-352].  Further,  the  explosion 
technique  is  used  to  diagram  data  flows  wherein  essential  processes  illustrated  in  the 
overview  diagram  (Figure  11)  explode  to  greater  levels  of  detail  in  subsequent  charts 
(Appendix  D). 
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a.  Overview  DFD 

The  overview  DFD  contains  all  of  the  entities  depicted  in  the  EMETRAK 
context  diagram  and  shows  how  they  logically  interact  with  the  three  major  system 
processes:  maintain  data,  conduct  analysis,  and  generate  reports.  There  is  only  one  data 
store  at  the  overview  level,  but  it  is  divided  into  smaller  data  stores  in  lower  level  DFDs. 

Process  P  1  receives  data  input  from  the  EME  staff  at  NPS  (EME),  the 
program  manager  (NSHS),  BUPERS,  and  the  customer  sites  (MTFs).  Process  P  1  then 
transforms  (i.e.  adds,  modifies,  or  deletes)  the  data  and  sends  the  output,  “updated 
program  information”,  to  temporary  storage  in  DB  .EMETRAK. 

Processes  P  2  and  P  3  perform  similar  operations  on  EME  data  and 
produce  various  queries  or  reports  for  the  requesting  external  entities. 
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b. 


Level  One  DFDs 


Level  One  DFDs  detail  the  major  processes  identified  in  the 
decomposition  diagram  and  the  overview  DFD. 

In  the  Level  one-Process  one  chart  (Appendix  D,  p.  107),  EME  provides 
officer  and  course  data  inputs,  NSHS  provides  command  and  billet  information,  MTFs 
submit  class  rosters,  and  BUPERS  provides  the  master  Officer  List.  Each  sub-process  (P 
1.1  through  1.5)  transforms  the  data  flows  into  “updated  information”  for  the 
DB.EMETRAK  data  store.  The  MTFs  provide  feedback  to  the  system  in  the  form  of 
“verified  officer  information”  to  the  Update  Officer  Information  process  (P  1.1).  The 
only  output  at  this  level  is  the  “file  export”  data  flow  to  the  program  manager  (NSHS). 

Level  one-Process  two  (Appendix  D,  p.  108)  shows  “program  data” 
flowing  from  the  data  store  (DB.EMETRAK)  and  being  transformed  into  either  a 
“structured  query”,  “interactive  query”,  or  “program  statistics”.  The  query  capability  is 
available  to  all  external  entities,  however,  statistics  are  only  provided  to  EME  and  NSHS 
for  program  management  purposes. 

Level  one-Process  three  (Appendix  D,  p.  109)  is  very  similar  to  the 
previous  diagram  but  for  structured,  interactive,  and  statistical  reporting. 


c.  Level  Two  DFDs 

In  level  two,  the  process  one  functions  are  more  closely  examined  and  the 
DB.EMETRAK  data  store  is  divided  into  smaller  logical  data  stores  (Figure  12). 

Process  1.1  adds,  modifies  or  deletes  basic  officer  information  in  the 
system  (Appendix  D,  p.  1 10).  The  external  agencies  that  interact  with  the  system  are 
EME,  NSHS,  and  the  MTFs.  EME  or  NSHS  provide  “officer  information”  to  the  Add 
Officer  process  (P  1.1.1#).  The  MTF  provides  “verified  of  officer  information“  and  P 
1.1.1#  transforms  the  two  data  flows  into  a  “new  officer  entry”  which  is  placed  in  the 
OFFICER  data  store  (DS  1).  In  P  1.1.2#,  EME  or  NSHS  provide  “additional  officer 
information”  which  is  used  to  modify  existing  data  in  DS  1.  In  P  1.1.3#,  EME  or  NSHS 
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provide  the  “officer  identification  number”  which  is  transformed  into  an  “officer  to 
delete”  data  flow.  In  the  last  process,  Change  Officer  Location  (P  1.1.4#),  EME  or  NSHS 
provide  a  “new  location”  which  is  transformed  into  an  officer’s  “new  officer  location”  in 
DS  1. 

Process  1.2  (Appendix  D,  p.  Ill)  adds  or  modifies  course  information  in 

9 

the  database  or  assigns  a  course  to  an  EME  competency  category.  EME  or  NSHS 
provide  “new  course”  or  “additional  course  data”  input.  The  Add  Course  and  Modify 
Course  Information  processes  (P  1.2.1#  and  P  1.2.2#)  transform  their  respective  data 
flows  which  update  information  in  the  COURSE  data  store  (DS  2).  EME  or  NSHS  also 
provide  “course  and  competency  information”  which  is  transformed  into  a  “new 
competency  classification”  and  is  stored  in  the  COMPETENCY  data  store  (DS  5). 


DS1  OFFICER 


DS  2  COURSE 


DB.EMETRAK 


DS  3  UlC 


DS4  CLASS 


DS  5  COMPETENCY 


DS6  BACKUP 

Figure  12.  EMETRAK  Data  Decomposition  Diagram 


Process  1.3  (Appendix  D,  p.  112)  adds,  modifies,  and  deletes  command 
information  of  EME  participants.  NSHS  provides  input  to  the  Add  Command,  Modify 
Command  Information,  and  Delete  Command  processes  (P  1.3.1#,  P  1.3.2#,  and  P 
1.3.3#).  Each  process  performs  an  operation  on  the  data  which  updates  the  UIC  data 
store  (DS  3). 


Process  P  1.4  (Appendix  D,  p.  113)  addresses  adding  classes  and 
modifying  class  information.  The  Add  Class  process  (P  1.4.1#)  receives  input  from 
EME,  the  MTF  and  the  COURSE  data  store  (DS  2).  EME  provides  “verified  officer 
information”  and  the  MTF  provides  the  validation  of  a  class  occurrence  by  initiating  the 
“class  roster”  input.  The  process  also  extracts  the  course  number  and*  course  name  from 
DS  2.  All  inputs  are  transformed  into  a  new  class  occurrence  for  a  specific  officer  in  the 
CLASS  data  store  (DS  4).  Modify  Class  Information  (P  1.4.2#)  simply  receives  input 
from  EME  and  modifies  existing  data  in  DS  4.  ^ 

Import/Export  Information  (P  1.5)  defines  the  utility  functions  of  the 
system  (Appendix  D,  pp.  1 14-1 17).  P  1.5.1#  shows  the  system  back  up  function,  process 
P  1.5.2#  illustrates  the  BUPERS  officer  master  data  file  import,  and  processes  P  1.5.3# 
and  P  1.5.4#  depict  the  file  import/export  functions  between  the  EME  office  at  NPS  and 
the  program  manager. 


D.  THE  DATA  MODEL 

A  major  goal  in  the  early  stages  of  database  development  is  to  build  a  data  model 
that  documents  the  entities  to  be  represented  in  the  database,  to  determine  the 
characteristics  of  those  entities,  and  to  describe  the  relationships  among  them.  A  method 
known  as  semantic  object  modeling  is  used  to  study  and  document  the  entities,  known  as 
semantic  objects,  to  be  stored  in  the  database.  A  semantic  object  is  a  representation  of 
something  identifiable  in  the  user’s  work  environment  or  business  process.  It  is  a  “named 
collection  of  attributes”  that  sufficiently  describes  a  distinct  identity  [Ref  9,  pp.  79-81]. 
The  “named  collection  of  attributes”  represents  all  of  the  characteristics  that  the  users 
need  to  accomplish  their  tasks.  The  SALSA®  software  application  is  used  to  construct 
semantic  object  diagrams  and,  ultimately,  a  database  schema.  Semantic  object  diagrams 
summarize  the  structures  of  objects  in  a  system  and  visually  present  them. 
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1. 


Semantic  Objects 


Five  internal  entities  or  objects  in  the  EMETRAK  system  identified  in  the 
previous  chapter  are  modeled:  OFFICER,  UIC,  CLASS,  COURSE,  and  COMPETENCY. 
A  new  object,  COURSECOMP,  is  also  modeled  that  describes  an  instance  of  an  EME 
course  assigned  to  a  particular  competency  category. 

The  OFFICER  object  (Figure  13)  describes  an  officer  enrolled  in  the  EME 
program.  The  officer  is  uniquely  identified  by  the  SSN  and  has  a  group  attribute  called 
OfficerName.  The  Officer  Name  group  attribute  consists  of  the  LastName,  FirstName, 
and  Minitial  simple  attributes.  Other  simple  attributes  that  describe  the  officer  are  Rank, 
BSC  (billet  sequence  code),  Designator,  Subspecialty,  JobTitle,  and  Email  (address).  The 
OFFICER  object  is  related  to  the  UIC  and  CLASS  semantic  objects.  The  integers  to  right 
of  the  object  attributes  are  the  attribute’s  minimum  and  maximum  eardinality.  The 
minimum  cardinality  is  the  minimum  number  of  instances  of  the  attribute  that  must  exist 
for  the  object  to  be  valid.  The  maximum  cardinality  indicates  the  maximum  number  of 
instances  that  an  attribute  may  have.  In  the  OFFICER  object,  the  officer  is  related  to  one 
and  only  one  (1.1)  command  (UIC)  and  may  be  related  to  zero  or  many  (O.N)  instances  of 
a  CLASS. 

The  UIC  object  is  uniquely  identified  by  the  UICNumber  attribute.  It  has  the 
following  additional  attributes:  UICName,  Address,  Phone,  and  HealthSvRegion.  The 
UIC  object  may  have  from  zero  to  many  officers  assigned  as  indicated  by  the  cardinality 
of  the  OFFICER  object  contained  within  UIC. 

The  CLASS  object  has  a  unique  composite  identifier  consisting  of  the  OFFICER 
ID  (Ssn)  and  COURSE  ID  (CourseNumber).  The  CLASS  object  is  an  instance  of  an 
officer  taking  an  EME  course  on  a  specific  date.  The  CLASS  attributes  are  ClassDate, 
Instructor,  and  CourseLocation. 
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Figure  13.  OFFICER,  UIC,  and  CLASS  Semantic  Objects 

The  COURSE  semantic  object  (Figure  14)  describes  an  EME  course  offering.  It 
consists  of  the  CourselD,  CourseName,  Hours,  CEUCredits,  CourseDesc  (description), 
and  CourseSponsor  attributes.  A  COURSE  may  be  related  to  zero  or  many  instances  of 
CLASS  but  must  belong  to  at  least  one  competency  category  (COURSECOMP). 

The  COURSECOMP  object  is  identified  by  a  composite  identifier  consisting  of 
CourselD  from  the  COURSE  object  and  Competency  from  the  COMPETENCYCAT 
object.  The  COURSECOMP  object  models  an  intersection  relation  between  the  two 
objects  which  will  be  helpful  during  database  implementation  to  overcome  certain  data 
anomalies  described  in  the  next  chapter. 

The  COMPETENCYCAT  object  is  uniquely  described  by  the  Competency 
attribute  which  is  simply  the  EME  competency  category  title. 


H  COURSE  \m 

ID  CourselD 

CourseName 

Hours 

CEUCredits 

CourseDesc 

CourseSponsor 

I  CiASS 

’  COURSECOMP  I,, 

H  COMPETENCycaY  Ig: 

jD  Competency 

j  COURSECOi^  ,  , 


Figure  14.  COURSE,  COURSECOMP,  and  COMPETENCYCAT  Semantic  Objects 
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E.  LESSONS  LEARNED  DURING  THE  SYSTEMS  DEFINITION  PHASE 


The  modeling  techniques  used  in  this  phase  facilitated  a  comprehensive  study  of 
the  business  processes  employed  by  both  the  EME  program  management  group  and 
administrative  staff.  The  capabilities  desired  by  the  system  owner  and  users  drove  the 
detailed  nature  of  the  study.  Translating  those  desired  capabilities  into  proposed  system 
functions  required  a  thorough  understanding  of  the  day-to-day  administrative  procedures 
as  well  as  the  overall  EME  program  management  strategy  and  objectives.  The  techniques 
discussed  in  this  chapter  helped  achieve  that  goal. 

Two  key  decisions  occurred  during  the  Systems  Definition  phase  that  impact  the 
future  development  of  the  EMETRAK  system.  First,  the  program  manager  at  NSHS 
expanded  the  scope  of  EMETRAK  concomitant  with  the  two-phased  development 
strategy  articulated  in  the  previous  chapter.  The  concept  for  the  development  of  a  multi¬ 
user  database  application,  accessible  from  every  major  Navy  MTF,  was  approved  and 
funded  as  part  of  the  FY-96  program  budget.  This  decision  reinforced  the  notion  of  using 
a  4GL  rapid  application  development  tool  to  build  a  working  prototype. 

A  working  prototype  would  provide  the  EME  staff  with  an  immediate  data 
collection  and  reporting  capability  while  a  final  production  system  is  developed. 
Moreover,  the  prototype  system  could  serve  as  an  adjunct  to  the  written  requirements 
specification  to  more  accurately  define  multi-user  requirements  in  terms  of  data 
structures,  user  interface,  and  system  outputs. 

The  second  decision  was  approval  of  the  concept  to  partner  with  the  Defense 
Manpower  Data  Center  (DMDC)  to  develop  the  multi-user  system  (Phase  II).  The  terms 
of  the  partnership  are  not  final,  but  they  involve  developing  the  requirements 
specification  as  part  of  this  study  and  turning  those  products  over  to  DMDC  programmers 
for  coding  and  testing.  Under  this  plan,  the  EME  Program  would  reimburse  DMDC  for 
the  level  of  effort  and  materials  required  for  system  development.  While  the  exact  level 
of  effort  required  is  undetermined  at  this  stage,  a  DOD  partnership  should  result  in 
significantly  lower  development  costs  compared  to  those  predicted  in  the  cost-benefit 
analysis. 
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IV.  SYSTEMS  DESIGN  PHASE 


Database  and  application  design  are  the  major  themes  of  this  chapter.  The 
relational  model  is  the  foundation  for  database  design  and  applies  to  both  the  single-user 
and  multi-user  versions  of  EMETRAK.  Application  design,  however,  focuses  on  the 
design  of  specific  database  components  and  the  user  interface.  These  components  are 
peculiar,  in  some  cases,  to  Microsoft  Access®  therefore  application  design  issues  as 
discussed  in  this  chapter  are  restricted  to  the  single-user  system  (Phase  I).  Multi-user 
application  design  issues  are  addressed  in  a  subsequent  chapter. 


A.  DATABASE  DESIGN 

Transformation  of  the  semantic  object  model  into  a  relational  database  design  is  a 
two  step  process.  First,  the  semantic  objects  are  converted  into  a  relational  model.  The 
relational  model  is  important  because  it  expresses  a  database  management  system 
(DBMS)  independent  design.  The  relational  model  is  comprised  of  relations  which  are 
two-dimensional  tables  storing  data  pertinent  to  the  original  semantic  themes. 
Representing  semantic  objects  as  relations  facilitates  normalization.  Normalization  is  a 
fundamental  concept  in  relational  database  design  and  is  the  process  of  converting  a 
relation  that  has  certain  problems  into  two  or  more  relations  that  do  not  have  these 
problems.  [Ref.  9,  p.  125]  The  problems  alluded  to  are  known  as  modification  anomalies 
and  refer  to  operations  requiring  several  steps  to  either  insert  or  delete  data  as  opposed  to 
one  atomic  operation  that  updates  data  in  multiple  related  tables  at  once. 

The  second  step  in  the  transformation  process  is  constructing  a  database  schema. 
The  database  schema  is  a  set  of  rules  that  defines  the  relational  database  structure,  its 
domains,  tables,  and  relationships.  A  database  schema  can  be  thought  of  as  data  that 
describes  the  database.  Most  modem  database  modeling  tools,  such  as  SALSA®, 
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automatically  generate  a  database  schema  which  is  imported  into  a  specific  DBMS  as  a 
template  for  the  application’s  database  tables. 


1.  Relational  Model 

Relations  consist  of  rows,  also  known  as  tuples,  and  columns.  The  intersection  of 
the  rows  and  columns  are  called  cells.  In  order  to  qualify  as  a  relation,  a  table  must 
conform  to  some  basic  rules  which  govern  the  content  of  its  rows,  columns,  and  cells 
[Ref.  9,  p.  126]: 

•  Each  cell  in  a  table  must  be  single-valued  (no  repeating  groups  or  arrays  are 
allowed) 

•  Each  column  in  a  table  must  have  a  unique  name 

•  All  entries  in  a  colunrn  must  be  of  the  same  kind  (or  theme) 

•  All  rows  in  a  table  are  unique  (no  two  are  identical) 

•  The  order  of  the  rows  or  columns  in  a  table  is  insignificant 

The  unique  names  of  the  columns  in  a  relation  are  called  attributes.  These 
attributes  correspond  to  the  same  attribute  names  represented  in  the  semantic  object 
model  in  Chapter  III.  Unique  rows  in  a  relation  are  identified  by  an  attribute  called  the 
primary  key.  Notice  that  no  two  rows  in  a  relational  table  can  have  the  same  primary  key 
and  duplicate  data  as  this  violates  the  rules  of  a  relation.  The  ID  attributes  from  the 
semantic  object  model  become  primary  keys  in  the  relational  model  and  eventually  in  the 
database  tables. 

One  of  the  reasons  for  selecting  the  semantic  object  modeling  technique  was  that 
relationships  between  semantic  objects,  and  ultimately  relations,  are  automatically 
generated  by  the  software  modeling  tool.  The  only  manual  task  required  of  the  developer 
is  to  identify  many  to  many  (M:N)  relationships  between  objects  and  divide  these  into 
separate  one  to  many  (1:N)  relations  to  comply  with  standard  normalization  rules.  The 
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other  advantage  of  using  semantic  object  modeling  is  that  normalization  problems 
associated  with  relational  database  design  are  less  likely  than  with  other  methods  such  as 
entity-relationship  models  because  objects  already  conform  to  semantic  themes.  This  is 
the  essence  of  normalization  -  every  normalized  relation  has  a  single  theme. 

Relations  are  further  classified  by  the  types  of  modification  anomalies  to  which 
they  are  vulnerable.  Without  explaining  the  details  of  each  normal  form,  suffice  it  to  say 
that  the  goal  for  the  EMETRAK  relational  model  is  third  normal  form  which  eliminates 
most  of  the  modification  anomalies.  A  relation  in  third  normal  form  has  the  following 
characteristics: 

•  A  table  containing  data  must  meet  the  definition  of  a  relation 

•  All  of  the  non-key  attributes  in  a  relation  depend  on  all  of  the  primary  key 

•  None  of  the  attributes  of  relations  have  transitive  dependencies 

The  EMETRAK  relational  model  consists  of  six  relations  and  their  corresponding 
relationships  (Figure  15).  The  underlined  attributes  represent  primary  keys  in  a  relation 
and  italicized  attributes  represent  foreign  keys.  Foreign  keys  are  the  linking  mechanism 
to  a  related  table.  Notice  that  foreign  keys  in  one  relation  are  the  primary  key  in  a  linked 
relation.  Lastly,  the  cardinalities  from  semantic  object  attributes  transform  into 
relationships  in  the  relational  model. 


a.  UIC  Relation 

An  instance  or  single  occurrence  in  the  UIC  relation  is  uniquely  identified 
by  its  UIC  Number  which  is  the  primary  key.  A  UIC  may  have  from  zero  to  many 
officers  assigned  but  an  officer  must  be  related  (assigned)  to  a  specific  UIC.  The  UIC 
and  OFFICER  relations  are  linked  through  a  foreign  key  (UIC)  appearing  as  an  attribute 
in  the  OFFICER  relation. 
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OFFICER  Relation 


b. 

An  officer  is  identified  by  a  unique  SSN  and  may  have  completed  from 
zero  to  many  classes.  However,  a  CLASS  occurrence  must  be  related  to  an  OFFICER 
instance  to  exist. 


c.  CLASS  Relation 

The  CLASS  relation  is  an  occurrence  of  an  officer  talcing  an  EME  course. 
The  primary  key  in  the  CLASS  relation  is  a  composite  key  consisting  of  foreign  keys 
from  both  the  OFFICER  and  COURSE  relations.  These  foreign  keys  link  the  two 
relations  to  CLASS.  A  CLASS  must  be  related  to  an  occurrence  of  COURSE  to  exist. 


d.  COURSE  Relation 

A  COURSE  is  identified  by  a  unique  course  number  -  the  CourselD 
attribute.  A  COURSE  may  be  related  to  zero  or  many  occurrences  of  CLASS.  A 
COURSE  may  also  belong  to  several  EME  competency  categories. 


e.  COMPETENCYCAT  Relation 

The  COMPETENCYCAT  relation  represents  the  various  competency 
categories  addressed  by  the  EME  program.  An  instance  in  the  COMPETENCYCAT 
relation  is  identified  by  the  competency  title  specified  in  the  program  literature.  A 
competency  category  has  many  associated  courses  and  an  EME  course  may  belong  to 
several  competency  categories.  This  situation  represents  a  many  to  many  (M;N) 
relationship  which  is  susceptible  to  a  variety  of  modification  anomalies  during  database 
implementation.  Normalization  rules  require  that  many  to  many  (M;N)  relations  be 
divided  into  two  or  more  one  to  one  (1:1)  relations  to  reduce  modification  anomalies. 
The  solution  is  constructing  the  intersection  relation  COMPCOURSE. 
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f. 


COMPCOURSE  Relation 


The  COMPCOURSE  intersection  relation  stores  very  little  data;  it  is 
simply  a  listing  of  EME  competencies  and  associated  course  numbers.  The  composite 
primary  key  for  the  COMPCOURSE  relation  consists  of  foreign  keys  from  the 
COMPETENCYCAT  and  COURSE  relations. 

The  many  to  many  relationship  between  the  course  and  competency 
category  relations  only  became  apparent  during  the  development  of  the  relational  model. 
The  semantic  object  model  had  to  be  later  modified  to  reflect  the  development  of  the  new 
intersection  relation. 


2.  Database  Schema  and  Table  Generation 

SALSA®  generates  the  database  schema  in  an  exportable  format.  The  schema  is 
then  imported  into  the  DBMS  application  and  the  basic  structure  for  database  tables  is 
developed  from  the  semantic  object  domain,  attribute,  and  relationship  code.  Although 
somewhat  automatic,  the  table  generation  process  still  requires  the  developer  to  perform 
minor  modifications  on  table  relationships,  attribute  names,  and  field  lengths.  Once  the 
tables  are  generated  in  the  DBMS  application,  developers  can  begin  to  focus  on 
application  and  user  interface  design. 
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Figure  15.  Relational  Diagram 


B. 


APPLICATION  DESIGN 


1.  General  Considerations 

When  designing  the  EMETRAK  prototype  application,  several  factors  and 
considerations  were  taken  into  account.  First,  the  application  was  designed  to  fulfill  the 
system  owner’s  requirements  and  support  the  EME  program  objectives.  Second,  since 
end-users  were  not  likely  to  use  the  application  every  day,  it  had  to  have  an  intuitive  and 
user-friendly  interface.  Finally,  the  prototype  had  to  provide  clear  and  complete 
specifications  to  the  programmers  who  would  later  be  developing  the  multi-user  system. 
Consequently,  application  design  required  close  coordination  between  the  developers,  the 
system  owner  and  several  prospective  end-users.  The  system  owner  was  involved  in  the 
approval  of  form,  query,  and  report  design  and  approved  each  component  for  logic  and 
correctness.  Because  the  EMETRAK  Phase  I  application  was  a  prototype  design,  some 
sacrifices  in  efficiency,  security,  and  error  handling  were  accepted  in  favor  of  rapid 
application  development. 


2.  Principles  of  Interface  Design 

The  Microsoft  Windows®  basic  user  interface  design  principles  described  by  the 
event  driven  programming  model  were  adhered  to  during  application  design.  [Ref  10,  p. 
34-35] 

•  User  in  Control  -  In  the  event  driven  programming  model,  the  application 
should  be  the  servant  not  the  master.  The  user  controls  the  actions  of  the 
application  not  the  reverse. 

•  Directness  -  The  application  should  be  straight-forward  in  its  design.  Users 
do  not  want  to  deal  with  files,  bytes,  ete.  The  user  should  be  able  to  select  an 
object  (form,  input  box,  button,  etc.)  and  perform  an  action  on  that  object. 
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•  Consistency  -  End-users  want  to  know  what  to  expect  in  an  application.  The 
sooner  a  user  is  comfortable  with  the  application,  the  sooner  they  stop 
working  with  a  program  and  start  using  a  tool. 

•  Clarity  -  The  design  should  have  intuitive  entry  forms  and  message  boxes  for 
data  exchange.  The  entities  represented  in  the  tables  should  have  one  theme 
and  make  sense. 

•  Aesthetics  -  Color  and  layout  are  important.  Users  want  crisp  eye-pleasing 
displays  not  garish  designs. 

•  Feedback  -  Providing  immediate  feedback  to  end-users  when  an  event  teikes  a 
substantial  amount  of  time  is  an  important  design  concept.  This  feature  lets 
the  user  know  they  have  temporarily  relinquished  control  of  the  application 
while  background  processing  is  being  accomplished. 

•  Forgiveness  -  The  application  should  allow  the  user  to  recover  from  mistakes 
easily  and  without  crashing.  Access  2.0  provides  a  built-in  multi-level  undo 
function  which  was  used  in  the  EMETRAK  design  along  with  warnings  and 
dialog  message  boxes. 


a.  EMETRAK  Design 

EMETRAK  was  designed  with  a  branching  architecture  rather  than  the 
typical  hierarchical  menu  structure  found  in  many  database  applications.  The  application 
opens  directly  to  a  main  input  form  titled  Officer  Record  from  which  the  user  can 
immediately  view  officer  information  or  navigate  to  other  application  features.  Buttons 
that  “branch”  or  link  to  other  application  functions  such  as  table  views,  reports,  and 
utilities  are  all  easily  accessible  on  the  main  input  form. 
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3.  Input  Forms  and  Menus 


a.  Officer  Record  Form  (Figure  16) 

Most  of  the  information  relevant  to  an  officer  enrolled  in  the  EME 
program  appears  on  the  Officer  Record  form.  Basic  information  from  the  officer  data  file 
appears  in  text  boxes  in  the  upper  half  of  the  form  and  a  sub-form  showing  officer 
transcript  information  appears  on  the  lower  half  of  the  form.  By  selecting  an  object- 
action  button  on  the  Ojficer  Record  form,  the  user  can  view  information  about  an 
officer’s  command,  see  how  many  program  hours  an  officer  has  completed  sub-divided 
by  competency  category,  or  add  information  on  a  completed  course.  Buttons  on  the 
Officer  Record  form  also  allow  the  user  to  view  system  tables,  access  the  reports  menu, 
and  edit  officer  data. 

b.  Command  Info  Form  (Figure  17) 

The  Command  Info  form  opens  when  the  Display  UIC  button  is  selected. 
The  form  displays  the  officer’s  unit  title,  address,  telephone  number,  and  HSR. 
Command  information  may  be  updated  directly  on  the  Command  Info  form. 

c.  Add  New  Class  Form  (Figure  18) 

The  Add  New  Class  form  opens  on  top  of  the  Officer  Record  form  when 
the  appropriate  button  is  selected.  The  Add  New  Class  form  allows  the  user  to  enter 
completed  course  information  on  any  officer  in  the  database  not  just  the  officer  record 
underlying  the  form.  Upon  entering  the  officer  SSN  in  a  text  box,  the  officer’s  name 
automatically  appears  on  the  form.  This  provides  the  user  with  instant  feedback  and 
verification  of  an  officer’s  name  and  SSN.  An  officer  must  first  exist  in  the  database 
before  entering  class  information. 
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d. 


Hours  by  Competency  Form  (Figure  19) 


Selecting  the  Competencies  button  on  the  Officer  Record  form  opens  the 
Hours  by  Competency  form.  This  form  shows  the  number  of  EME  hours  completed  by 
the  officer  grouped  by  competency  category.  The  system  owner  agreed  to  a  design  that 
shows  hours  completed  vice  completed  competency  categories  because  of  the  unresolved 
competency  issue  addressed  in  the  earlier  chapters. 


e.  View  Tables  Menu  (Figure  20) 

Selecting  the  Tables  button  sends  the  user  to  the  View  Tables  menu.  The 
View  Tables  menu  provides  the  user  with  the  ability  to  view  the  COURSE,  UIC,  or 
COMPETENCYCAT  tables.  Users  may  edit  data  stored  in  these  tables  in  the  prototype 
application. 


f.  Report  Menu  (Figure  21) 

The  Reports  button  on  the  Officer  Record  form  opens  the  Report  Menu. 
The  Report  Menu  provides  the  user  with  a  selection  of  ten  pre-formatted  reports  that  can 
be  viewed  in  a  tabular  query  form,  a  screen  report  format,  or  printed  in  hard  paper  copy. 


4.  Utility  Functions 

Six  buttons  on  the  right  side  of  the  Officer  Record  form  provide  basic  record  and 
file  utility  fiinctions.  The  user  may  add  a  new  officer  record,  save  modifications  to  the 
current  record,  find  a  specific  entry  in  a  selected  field,  toggle  to  the  next  or  previous 
record,  or  exit  the  application. 
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c. 


LESSONS  LEARNED  DURING  THE  SYSTEMS  DESIGN  PHASE 


The  prototyping  approach  was  used  to  validate  the  design  of  the  user  interface, 
screens  and  reports.  It  helped  clarify  system  requirements  and  reduce  uncertainty  with 
the  system  owner  during  development.  The  greatest  benefit  proved  to  be  in  soliciting 
input  from  the  system  owner  and  users  who  were  not  exactly  sure  about  what  they  wanted 
until  they  saw  it  on  a  computer  screen.  Moreover,  rapid  prototyping  facilitated 
constructive  user  comment  and  continuous  feedback  which  reduced  errors  in  application 
design. 
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V.  EMETRAK  PROTOTYPE  IMPLEMENTATION 


A.  PROTOTYPE  APPLICATION  STRUCTURE 

Relational  databases  apply  the  principles  of  the  relational  data  model  in  which 
data  is  organized  into  logical  mathematical  sets  in  a  tabular  structure.  This  allows  data  to 
be  stored  more  efficiently  and  with  less  overhead  than  older  file  management  or 
hierarchical  systems.  Efficiency  is  measured  in  terms  of  memory  requirements  and 
access  speed. 

While  efficiency  is  important,  database  quality  is  usually  the  primary  criteria  for 
selecting  for  a  particular  database  model.  The  quality  of  a  database  is  largely  determined 
by  the  accuracy  of  the  data  it  stores.  Therefore,  a  primary  goal  of  the  relational  database 
model  is  to  preserve  data  integrity.  Integrity  is  preserved  by  preventing  access  to  data 
from  outside  of  the  DBMS  that  created  it.  In  a  relational  database  management  system 
(RDBMS),  data  can  only  be  accessed  through  queries  handled  by  the  DBMS  engine 
itself  Thus  in  a  relational  system,  data  is  stored  in  linked  tables,  it  is  accessed  only 
through  DBMS  queries,  and  it  is  presented  in  database  forms  and  reports.  [Ref  1 1,  p.  16] 

Microsoft  Access  2.0®  is  a  true  RDBMS  application.  The  database  engine 
provides  strong  data  integrity  by  limiting  access  to  data  and  by  enforcing  robust 
referential  integrity  rules.  It  was  selected  for  development  of  the  EMETRAK  prototype 
system  due  to  its  intuitive  object-oriented  design  features,  simple  query  facility,  and 
powerful  database  engine.  Access  uses  tables,  queries,  forms,  reports,  macros,  and 
modules  in  its  DBMS  implementation. 
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1. 


Tables 


A  relational  database  is  designed  to  manage  information  stored  in  multiple  tables. 
Tables  contain  information  from  a  single  object  class  or  theme  organized  into  rows  and 
columns.  Each  row  represents  an  individual  record  and  the  columns,  called  fields,  are 
describing  characteristics  of  that  record.  Tables  are  created  in  Microsoft  Access  in  two 
ways.  A  database  schema  or  external  DBMS  table  is  imported  and  converted  into  an 
Access  table  or  a  new  table  is  created  from  within  the  application  itself 

The  prototype  system  consists  of  eight  tables  that  were  either  created  from  the 
imported  database  schema  or  developed  within  the  actual  application.  The  EMETRAK 
table  structures  are  described  in  the  prototype  database  dictionary  (Appendix  E). 


2.  Queries 

A  query  is  a  method  of  accessing  the  database  by  asking  the  DBMS  a  question  or 
by  sorting,  grouping,  or  updating  database  information.  These  functions  are  performed 
by  a  sub-language  known  as  Structured  Query  Language  (SQL).  SQL  was  explicitly 
designed  to  access  DBMSs  based  on  the  relational  model  [Ref  11,  p.  27].  Microsoft 
Access  uses  its  own  proprietary  version  of  SQL  based  on  the  American  National 
Standards  Institute  version  89  (ANSI-89  SQL)  standard  to  access  data.  Access  also 
provides  a  visual  interface  to  SQL  known  as  query-by-example  (QBE)  which  greatly 
simplifies  writing  database  queries.  Twenty-four  queries  were  written  for  the  prototype 
system  and  the  significant  ones  are  described  in  detail  in  Appendix  F. 


3.  Forms 

Database  forms  are  a  means  of  inputting  data  and  presenting  DBMS  information 
on  the  computer  screen.  Database  forms  usually  emulate  paper  forms  found  in  an 
existing  system  and  present  the  same  type  of  information  in  a  “paperless”  format.  Forms 
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are  usually  based  upon  system  queries  written  to  actually  present  or  manipulate  database 
information.  Prototype  system  forms  were  described  in  section  B  of  the  previous  chapter. 


4.  Reports 

A  report  is  either  a  paper  or  on-screen  presentation  of  information.  Access  2.0  has 
a  flexible  report  generation  capability  that  allows  the  development  of  reports  which 
closely  replicate  those  used  in  an  existing  system. 

Eleven  reports  were  developed  for  the  prototype  system.  The  only  existing 
system  report  which  was  replicated  was  the  course  completion  letter.  All  other  reports 
were  developed  based  upon  new  input  from  the  system  owner.  Each  report  was  designed 
with  a  similar  “look  and  feel”  to  present  a  standardized  format.  Prototype  system  reports 
are  provided  in  Appendix  G. 


5.  Macros 

Access  provides  a  powerful  capability  to  manipulate  database  objects  and 
automate  repetitive  tasks  through  the  use  of  macros.  A  macro  is  a  small  menu-driven 
sub-routine  that  provides  its  functionality  without  requiring  complex  coding  on  the  part 
of  the  developer.  Macros  were  used  extensively  in  the  prototype  system  to  quickly 
develop  menus  and  reports. 


6.  Modules 

A  module  is  a  container  within  Access  that  stores  Access  Basic  procedures. 
Access  Basic  is  a  programming  language  that  allows  the  developer  to  customize  database 
objects  by  defining  methods,  properties,  and  actions  through  code.  The  EMETRAK 
prototype  system  only  has  one  module.  The  functions  stored  in  that  module  are  described 
in  Appendix  H. 
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B.  REFINING  THE  PROTOTYPE  APPLICATION 


Once  the  basic  structure  of  a  prototype  database  is  completed  and  populated  with 
test  data,  the  developer  integrates  the  various  parts  into  a  working  application  before 
begirming  dedicated  system  testing.  Integration  and  refinement  include  such  things  as 
verifying  table  relationships,  standardizing  form  layouts,  developing  customized  menus, 
providing  a  back  up  capability,  and  establishing  user  permissions  or  other  security 
features. 

The  prototype  application  was  closely  reviewed  for  accuracy  of  table 
relationships,  keys,  and  referential  integrity  rules.  Once  the  mechanics  of  the  tabular 
structure  was  verified,  the  cosmetics  of  the  user  interface  layout  and  menu  structure  were 
addressed.  The  color  scheme  and  location  of  utility  buttons  on  each  form  was  adjusted  to 
provide  consistency  and  clarity.  Further,  a  customized  and  simplified  drop-down  menu 
bar  was  added  to  enhance  user  efficiency.  To  enable  an  adequate  back  up  facility,  the 
prototype  system  was  programmed  to  automatically  copy  database  files  to  floppy  disks 
using  a  DOS-based  batch  file  procedure  upon  exiting  the  application.  Finally,  the  Access 
security  facility  was  invoked  to  enable  user  log  on  and  password  protection.  User  access 
was  restricted  to  data  entry,  viewing,  and  printing.  The  user’s  ability  to  modify  the 
database  design  or  directly  access  table  structures  and  other  security  functions  was 
disabled. 


C.  OTHER  IMPLEMENTATION  ISSUES 

1.  System  Testing 

Testing  is  an  important  activity  of  the  Systems  Implementation  phase  because 
translation  of  user  requirements  into  a  working  system  is  very  complex  and  error  prone. 
A  top-down  program  development  strategy  was  used  for  the  prototype  system  to  provide 
a  structured  approach  to  both  system  coding  and  testing.  With  the  top-down  approach. 
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the  developer  starts  with  a  high  level  description  and  adds  system  components  in  a 
hierarchical  fashion.  The  developer  programs  in  increasing  levels  of  detail  until  the 
specified  functionality  is  achieved.  Moreover,  each  module  is  tested  along  the  way  for 
interoperability  with  its  parent  or  other  related  module.  The  advantage  of  this  approach  is 
that  integration  of  the  components  is  tested  as  the  application  is  being  developed  resulting 
in  smoother  systems  integration.  [Ref.  3,  pp.  312-313] 

Top-down  testing  involved  both  systems  integration  and  unit  testing  of  individual 
modules.  In  the  prototype  application,  the  highest  logical  level  module  was  tested  first 
and  then  each  related  module  was  independently  tested  using  up  to  250  records  of  test 
data.  As  problems  were  identified,  the  logic  of  the  module  was  corrected  until  the  desired 
functionality  was  attained.  Each  module  in  the  logical  structure  of  the  prototype  system 
was  unit  tested  and  no  major  problems  were  noted  at  the  completion  of  systems 
integration  testing. 

Once  system  testing  was  completed,  the  prototype  application  was  made  available 
to  the  EME  program  management  group  for  final  verification  and  validation.  Each 
application  function  was  demonstrated  to  the  group  and  compared  against  the  system 
owner’s  stated  requirements.  System  outputs  were  closely  scrutinized  by  the  system 
owner  and  the  program  manager  at  NSHS  before  final  approval  for  installation  was  given. 


2.  Training 

a.  User’s  Guide 

A  system  user’s  guide  was  developed  for  the  prototype  application 
(Appendix  I).  The  usability  of  the  guide  was  then  tested  on  a  randomly  selected  end-user 
who  was  not  familiar  with  either  the  prototype  application  or  the  contents  of  the  user’s 
guide.  The  end-user  was  instmcted  to  treat  the  guide  as  a  tutorial  for  the  prototype 
application.  The  session  was  closely  monitored  and  suggestions  from  the  end-user  were 
included  in  the  final  version  of  the  guide  before  distribution. 
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application.  The  session  was  closely  monitored  and  suggestions  from  the  end-user  were 
included  in  the  final  version  of  the  guide  before  distribution. 

b.  Formal  Training 

Two  training  sessions  were  conducted  for  approximately  eight  end-users 
before  system  installation.  The  training  sessions  encompassed  a  review  of  the  user’s 
guide,  an  application  demonstration,  and  hands-on  experience  with  the  prototype. 
Although  formal  training  was  deemed  effective  by  the  administrative  staff,  continuous 
technical  support  is  anticipated  in  the  months  ahead  until  the  multi-user  system  is  fielded. 


3.  Installation 

The  prototype  application  is  installed  on  a  networked  486/66  DX2  PC  with  a  420 
megabyte  hard  drive,  16  megabytes  of  random  access  memory,  and  a  network  printing 
option  installed.  The  PC  uses  Windows  3.1 1  and  the  Banyan  network  operating  system. 
The  prototype  application  runs  within  the  Microsoft  Access  2.0  DBMS  not  as  a  stand¬ 
alone  program. 

During  the  installation,  the  data  files  were  separated  from  the  application  and 
moved  to  another  directory  to  reduce  the  possibility  of  data  corruption  due  to  program 
failure.  Consequently,  the  DBMS  tables  are  attached  through  address  pointers  rather  than 
actually  residing  in  the  prototype  application. 

A  problem  was  encountered  with  activating  the  network  printing  option  in  the 
prototype  application.  After  consulting  with  the  network  administrator,  the  problem  was 
resolved  at  the  network  vice  application  level  and  printing  was  enabled.  The  final  step  in 
installation  was  activating  system  security  and  encrypting  the  database. 
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D.  POST-IMPLEMENTATION  EVALUATION 


Evaluation  is  an  important  tool  in  the  SDLC  to  assess  the  success  of  a  system  and 
recommend  improvements  for  subsequent  versions  or  follow-on  applications.  Two 
methods  will  be  used  to  evaluate  the  success  of  the  prototype  application:  1)  establishing 
a  help  desk  and  2)  conducting  a  user  survey.  The  help  desk  personnel  will  not  only 
provide  technical  support  to  the  end-users,  but  will  also  collect  data  on  prototype 
application  problems.  Suggested  areas  for  improvement  will  be  incorporated  in  the 
multi-user  application. 

The  user  survey  is  a  more  formal  mechanism  for  evaluating  the  prototype  system. 
However,  the  survey  will  not  be  conducted  until  the  prototype  system  has  been 
operational  for  several  months  and  end-users  are  thoroughly  familiar  with  the  application. 
Therefore,  help  desk  comments  will  provide  feedback  sooner  than  the  user  survey. 


E.  LESSONS  LEARNED  FROM  IMPLEMENTATION 

The  prototype  system  was  functional  and  capable  of  meeting  the  system  ovmer’s 
basic  requirements  for  data  entry  and  reporting  within  the  six  week  deadline.  However, 
incorporating  more  robust  capabilities  and  completing  the  finished  product  took 
considerably  longer.  A  calculation  of  development  hours  required  revealed  that 
approximately  1050  hours  were  needed  to  fully  develop  the  prototype  system  from  the 
analysis  phase  through  implementation.  The  function  point  and  comprehensive  cost 
model  analyses  conducted  in  the  cost-benefit  analysis  had  estimated  that  approximately 
1171  hours  would  be  required  to  develop  the  system.  Therefore,  the  conclusion  is  that 
the  models  were  an  effective  tool  for  estimating  development  time  in  this  case. 
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VI.  PHASE  II  -  THE  MULTI-USER  SYSTEM 


A.  INTRODUCTION 

The  decision  to  proceed  with  the  development  of  a  multi-user  system  was  driven 
by  the  program  manager’s  desire  to  involve  both  the  MTF  and  individual  officer  more 
closely  in  the  EME  educational  process.  While  multi-user  systems  are  generally  more 
expensive  and  complex  to  implement  than  single-user  systems,  the  benefits  derived  from 
increased  productivity  and  reduced  transaction  costs  can  far  outweigh  the  initial  cost. 
There  are  four  possible  methods  for  supporting  a  multi-user  database  system: 
teleprocessing,  client  server  computing,  resource  sharing,  and  distributed  systems. 

Teleprocessing  is  a  classic  legacy  implementation.  With  teleprocessing  all 
communications  control,  operating  system  functions,  applications,  and  DBMS 
components  reside  on  a  centralized  computer.  The  processing  is  completed  on  the 
centralized  central  processing  unit  (CPU)  and  information  is  displayed  on  remotely 
connected  dumb  terminals.  The  user  interface  is  often  character-based  and  extremely 
primitive  by  today’s  standards.  [Ref  9,  p.  507] 

Client  server  computing  consists  of  a  network  of  computers  connected  over  either 
a  local  area  or  wide  area  network.  Local  user  machines  are  referred  to  as  clients  and 
“back-end”  machines  are  called  servers.  In  the  database  context,  clients  run  application 
programs  and  servers  store,  manage,  and  process  data.  The  server  performs  data  integrity 
checking,  concurrent  access  controls  to  records,  and  maintains  the  overhead  data.  A 
client  server  system  tends  to  place  the  application  closer  to  the  end-user  resulting  in  better 
performance  and  more  sophisticated  user  interfaces.  [Ref.  9,  p.  507] 

Resource  sharing  systems  also  involve  networked  computers.  The  primary 
difference  between  resource  sharing  and  client  server  systems  is  in  the  services  provided 
by  the  “back-end”  server.  In  the  resource  sharing  environment,  the  server  usually 
provides  fewer  services,  requiring  instead  that  more  information  be  passed  between 
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processors.  Resource  sharing  systems  traditionally  require  more  bandwidth  and  have 
decreased  throughput  when  compared  to  the  other  alternatives.  [Ref.  9,  p.  507] 

Distributed  systems  are  implemented  in  two  ways:  distributed  processing  and 
distributed  data.  Distributed  processing  is  the  ability  for  more  than  one  interconnected 
processor  to  be  operating  at  a  time.  This  means  processing  an  application  on  more  than 
one  computer  at  a  time.  Distributing  data  is  dividing  the  database  and  distributing 
portions  throughout  the  system.  Both  approaches  present  significant  problems  for 
synchronizing  data  over  a  widely  distributed  system.  The  use  of  distributed  database 
technology  also  requires  developing  system-wide  rules  to  govern  communication 
between  nodes,  data  accessibility,  program  and  file  transfers,  and  common  operating 
procedures.  These  factors  usually  mean  increased  cost  over  the  other  feasible  alternatives. 
[Ref.  14,  pp.  147-148] 

The  client  server  model  offers  a  multi-user  solution  which  best  fits  the  existing 
organizational  structure  and  meets  the  program  manager’s  requirements.  Because  the 
prototype  system  was  developed  as  a  relational  database  it  can  be  easily  migrated  to  the 
client  server  model.  Client  server  databases  ensure  excellent  data  integrity  by  enforcing 
stringent  concurrent  access  rules.  Client  server  systems  are  also  easily  scaleable  from 
local  area  to  wide  area  networks.  Network  traffic  is  less  in  client  server  systems  than  in 
resource  sharing  which  is  a  significant  concern  with  the  small  amount  of  available 
bandwidth  in  most  wide  area  networks.  Moreover,  the  client  server  model  is  not  as 
complex  as  distributed  systems  and  reduces  the  inherent  synchronization  problems. 

This  chapter  analyzes  and  defines  the  requirements  for  the  multi-user  system 
based  on  the  client  server  model.  Coding  of  the  multi-user  application  will  be 
accomplished  by  programmers  at  DMDC  West  based  on  the  prototype  system  design  and 
information  provided  in  this  ehapter.  DMDC  has  considerable  experience  in  developing 
DOD  client  server  applications  and  will  provide  assistance  throughout  the  systems 
development  process  under  a  partnership  agreement  with  the  EME  program. 
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B.  ANALYSIS  PHASE 


The  SDLC  is  an  iterative  process  whereby  phases  are  re-visited  as  the 
environment  changes  and  the  deployment  of  a  system  proceeds.  This  section  examines 
issues  pertinent  to  the  development  of  the  multi-user  system. 

The  EMETRAK  multi-user  system  will  be  a  transaction-based  processing 
application  consisting  of  two  parts;  a  Windows-based  client  distributed  to  Navy  MTFs 
and  a  central  database  server.  Connectivity  between  the  client  applications  and  database 
server  will  be  accomplished  over  the  existing  Navy-wide  medical  network  or  via 
commercial  switched  networks  (Figure  22). 


PARTICIPATING  OFFICERS 

Figure  22.  Logical  Client  Server  Topology 


In  a  transaction  processing  system,  transactions  consist  of  a  query  string  sent  by 
the  client  and  a  data  set  returned  by  the  server.  Figure  23  illustrates  the  general  sequence 
of  events  in  a  client  server  system  when  an  end-user  accesses  the  database  server  over  the 
network. 
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Client  system 


Transaction 


Server  system 


Transaction 


— ►  Client  system 


Figure  23.  Client  Server  Transaction  Sequence  [Ref.  11] 

If  a  transaction  processing  application  is  properly  designed,  the  fact  that  the  data 
is  remotely  located  on  a  server  will  be  transparent  to  the  user.  However,  this  requires  that 
the  application  be  optimized  to  reduce  the  bandwidth  requirements  and  hence  the 
response  time  over  the  network. 

Responsiveness  of  transaction  processing  systems  is  affected  by  several  factors 
including:  transaction  size,  transaction  rate,  concurrent  network  traffic,  and  the  capacity 
of  the  network  connection.  Transaction  size  can  be  thought  of  as  the  physical  length  of 
the  query  string  and  the  size  of  the  data  set  that  is  returned.  The  transaction  rate  is  the 
number  of  requests  processed  by  the  system  in  a  specified  time  period.  Concurrent 
network  traffic  is  the  volume  of  data  on  the  network  with  which  the  transaction  must 
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compete.  The  capacity  of  a  network  connection  usually  ranges  from  9600  bits  per  second 
(modem  connection)  through  several  gigabits  per  second  for  advanced  optical  networks. 
The  current  NMDN  capacity  through  DISN  is  only  56  kbps. 

An  application’s  bandwidth  requirements  are  of  much  greater  concern  over  a 
WAN  because  the  available  bandwidth  is  usually  much  smaller  (almost  10  times  smaller) 
than  local  area  networks.  Bandwidth  concerns  lead  to  an  analysis  of  the  existing 
prototype  for  transaction  size  and  the  NMDN  for  traffic  volume. 


1.  Prototype  Peer  to  Peer  Test 

Testing  was  conducted  on  the  prototype  system  to  determine  an  approximate 
transaction  size  and  system  response  time.  It  has  to  be  noted  that  the  prototype  system 
was  not  designed  to  operate  over  a  network;  therefore,  it  was  not  optimized  for  the  peer- 
to-peer  network  configuration  in  which  it  was  tested.  However,  the  test  was  adequate  to 
provide  some  initial  planning  data.  The  test  revealed  that  the  average  transaction  size  of 
the  prototype  was  quite  large  at  approximately  50  kilobits  (kb).  Transactions  of  this  size 
resulted  in  slow  response  time  over  a  14,400  modem  direct  dial-up  connection. 

It  was  assumed  that  users  would  be  willing  to  endure  a  substantial  wait  (as  long  as 
one  minute)  on  initial  start-up  to  download  the  data  set  to  their  local  machines,  but  would 
then  expect  almost  immediate  response  when  toggling  through  records.  The  test  proved 
that  the  transaction  size  in  the  multi-user  system  must  be  considerably  smaller  than  50  kb 
to  achieve  acceptable  response  after  initial  start-up  delays. 

While  unable  to  exactly  determine  the  transaction  rate  for  the  EMETRAK  multi¬ 
user  system  at  this  stage,  it  is  anticipated  to  be  low  based  on  the  nature  of  the  application 
and  the  expected  number  of  simultaneous  users  (16). 
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2. 


Current  NMDN  Usage 


Bandwidth  usage  was  examined  over  several  of  the  existing  NMDN  wide  area 
connections.  NMIMC  used  HP  OpenView®  network  monitoring  software  to  collect  the 
data  from  three  sites  over  a  five  day  period  and  provided  the  information  at  the  request  of 
the  EME  program  office.  Table  6  is  a  summary  of  the  findings. 


Circuit 

Day 

Time 

0900 

1200 

1500 

units 

kilobits/sec 

(kbps) 

BUMED 

1.54  Mbps 

■■ 

14 

5 

5 

B 

17 

4 

7 

B 

12 

5 

11 

B 

18 

3 

5 

5 

14 

9 

6 

AVG 

15 

5.2 

6.8 

NSHS  Bethesda 

56  kbps 

■■ 

4 

1 

2 

B 

3 

5 

1 

B 

4 

5 

4 

H 

Down 

3 

1 

5 

2 

1 

2 

AVG 

3.25 

3 

2 

NH  Naples 

256  kbps 

■■ 

17 

13 

B 

19 

B 

11 

B 

Down 

5 

14 

■1 

■Ml 

AVG 

15.25 

15.25 

14 

Table  6.  NMDN  Network  Traffic  Summary 


Although  more  extensive  monitoring  is  required,  it  is  assumed  that  the  data  is 
representative  of  normal  network  traffic  volume.  The  initial  investigation  shows  that  the 
NMDN  has  excess  capacity  to  support  the  EMETRAK  multi-user  application  unless 
network  traffic  increases  significantly. 
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3.  Proposed  Changes  in  Bandwidth 


NMIMC  recognizes  that  the  current  56  kbps  connections  will  not  support  planned 
future  applications  such  as  multi-media  telemedicine  and  is  planning  to  increase  the 
capacity  during  the  next  several  fiscal  years.  Table  7  shows  the  planned  NMDN  DISN 
upgrades. 


Activity 

State 

Current  Capacity 

Planned  Upgrade 

NH  Bremerton 

WA 

56  kbps 

512  kbps 

NH  Oak  Harbor 

WA 

56  kbps 

256  kbps 

NH  Lemoore 

CA 

56  kbps 

256  kbps 

NH  Camp  Pendleton 

CA 

56  kbps 

512  kbps 

NMC  San  Diego 

CA 

56  kbps 

512  kbps 

NH  Corpus  Chrlsti 

TX 

56  kbps 

256  kbps 

NH  Pensacola 

FL 

56  kbps 

512  kbps 

NH  Millington 

TN 

56  kbps 

256  kbps 

NH  Camp  Lejeune 

NC 

56  kbps 

512  kbps 

NMC  Portsmouth 

VA 

56  kbps 

512  kbps 

NH  Patuxent  River 

MD 

56  kbps 

256  kbps 

NNMC  Bethesda 

MD 

56  kbps 

512  kbps 

NH  Groton 

CN 

56  kbps 

512  kbps 

NH  Great  Lakes 

IL 

56  kbps 

512  kbps 

Table  7.  NMDN  DISN  Planned  Bandwidth  Increases 


The  multi-user  application  will  benefit  from  the  planned  increase  in  WAN 
capacity,  however,  it  must  still  be  designed  to  operate  within  the  current  bandwidth 
limitations.  Moreover,  not  every  MAN  is  scheduled  to  receive  an  increase  in  capacity. 


C.  DEFINITION  PHASE 

This  section  specifies  the  multi-user  application  requirements  that  will  be 
delivered  to  DMDC  West  for  design  and  implementation.  The  process  and  data  models 
for  the  single-user  system  are  also  valid  for  the  multi-user  application  and  will  be 
referenced  in  this  section  as  well. 
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1. 


Connection  Methods 


EMETRAK  requires  two  connection  means  from  the  client  front-end  application 
to  the  database  residing  on  the  back-end  server.  The  primary  connection  protocol  desired 
for  the  application  is  transmission  control  protocol/intemet  protocol  (TCP/IP)  through  the 
existing  NMDN  via  DISN  or  the  Internet.  An  alternate  method  to  ensure  redundancy 
should  be  implemented  through  a  dial-up  connection  using  a  standard  modem  and  point 
to  point  protocol  (PPP). 


2,  Database  Views 

Different  views  of  the  database  are  required  in  the  multi-user  application.  Three 
views  of  the  data  are  envisioned:  program  management,  enterprise,  and  organizational 
views.  The  views  correspond  roughly  to  three  user  groups:  the  EME  program 
management  staff,  top  level  Navy  Medical  Department  executives,  and  the  individual 
MTFs.  Each  view  should  be  based  on  a  set  of  user  permissions  programmed  into  the 
client  application  and  enforced  by  the  database  server. 

The  views  are  unique,  but  are  not  necessarily  mutually  exclusive.  For  example, 
the  program  management  staff  would  have  privileges  to  access  all  views  and  to 
manipulate  the  database  (except  for  those  specifically  reserved  system  administrator 
functions).  Access  to  a  database  view  should  be  determined  through  a  combination  of  the 
user’s  UIC  and  password  during  system  log  on. 

•  Program  Management  view  -  The  program  management  view  of  the  database 
would  allow  the  user  to  see  all  tables,  queries,  forms,  and  reports  in  the 
application.  The  program  management  view  would  be  available  to  the  EME 
program  management  staff  at  NPS,  the  program  manager  at  NSHS,  Bethesda,  and 
the  EME  system  administrator  (with  additional  functions  provided). 
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•  Enterprise  view  -  The  enterprise  view  is  envisioned  as  an  executive  level  view. 
The  enterprise  view  would  provide  screen  reports  about  the  program  derived  from 
statistical  summaries.  The  enterprise  view  would  allow  the  user  to  “drill”  down 
and  see  officers  filtered  by  their  designator  number  or  see  information  about  an 
individual  officer,  if  desired.  The  enterprise  view  would  be  available  to  the 
Surgeon  General,  the  Medical  Department  Corps  Chiefs,  and  other  selected 
executives  at  BUMED,  BUPERS,  and  NSHS,  Bethesda,  MD. 

•  Organizational  view  -  The  organizational  view  would  center  on  the  officers 
assigned  to  a  specific  command  (UIC).  The  organization  would  be  able  to  view 
all  information  that  pertains  to  officers  in  the  command  or  within  a  specific 
designator  group  subject  to  a  filter.  Consequently,  the  OFFICER  and  CLASS 
table  views,  system  queries,  and  reports  should  be  based  on  the  appropriate  filter 
and  the  user’s  password.  All  UIC,  COURSE,  and  COMPETENCYCAT  tables, 
however,  could  be  viewed  in  the  organizational  view.  The  organizational  view 
would  be  available  to  all  MTFs  and  BUMED  specialty  advisors.  MTFs  would 
view  information  filtered  by  UIC  and  specialty  advisors  view  by  the  appropriate 
designator  number. 

Access  to  the  database  views  should  be  controlled  through  a  user  interface 
described  by  the  state  transition  diagram  in  Appendix  J. 


3.  User  Functions  and  Responsibilities 

This  section  specifies  who  may  perform  certain  functions  in  the  multi-user 

system. 
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Data  Maintenance  Function  (Figure  7) 


Update  Officer  Information  (Process  1.1) 

-  Add  Officer  -  SUPERS  and  EME  Staff 

-  Modify  Officer  Information  -  SUPERS,  EME  Staff,  and  MTF 

-  Delete  Officer  -  EME  Staff 

-  Change  Officer  Location  -  SUPERS 

Update  Course  Information  (Process  1.2) 

-  Add  Course  -  EME  Staff  (System  Administrator) 

-  Modify  Course  Information  -  EME  Staff  (System  Administrator) 

-  Assign  Course  to  Competency  -  EME  Staff  (System 
Administrator) 

Update  Command  Information  (Process  1.3) 

-  Add  Command  -  EME  Staff  (System  Administrator) 

-  Modify  Command  Information  -  MTF  and  EME  Staff  (System 
Administrator) 

-  Delete  Command  -  EME  Staff  (System  Administrator) 

Generate  Class  Information  (Process  1.4) 

-  Add  Class  -  MTF  and  EME  Staff 

-  Modify  Class  Information  -  MTF  and  EME  Staff 

-  Delete  Class  -  EME  Staff  (System  Administrator) 

Import/Export  Information  (Process  1.5) 

-  Create  Backup  and  Archive  (Process  1.5.1)-  EME  Staff  (System 
Administrator) 

-  Export  data  to  dblll  file  format  (Process  1.5.2)-  All  users 


-  Import  BUPERS  OFFICER  data  file  (Process  1.5.3)  -  EME  Staff 
(System  Administrator) 


4.  Required  Queries 

The  queries  listed  in  this  section  are  organized  according  to  the  EMETRAK 
process  model  (Figure  8).  They  are  further  grouped  according  to  the  database  views  that 
apply.  Queries  (structured  or  interactive)  may  be  combined  during  implementation  to 
support  various  screen  and  hard  copy  report  formats  as  required.  Implementation  of  an 
interactive  menu  of  queries  and  reports  similar  to  the  “SelectaRun”  form  in  the  prototype 
application  is  desired. 


a.  Run  Structured  Queries  (Process  2.1) 

(1)  Generic  queries 

•  All  course  modules 

•  All  course  modules  grouped  by  course  sponsor 

•  All  course  modules  grouped  by  competency  category 

•  All  competency  categories 

•  All  command  information  (UIC  number,  name,  address,  etc.) 

•  All  course  modules  delivered  in  the  last  90  days  and  their 
locations 

(2)  Queries  common  to  the  program  management  and 

enterprise  views 

•  All  officers  in  alphabetical  order 

•  All  officers  in  alpha  order  grouped  by  command  (UIC) 
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•  All  officers  in  alpha  order  and  completed  modules  grouped  by 
command  (UIC) 

•  All  officers  in  alpha  order  and  completed  modules 

•  All  officers  in  alphabetical  order  grouped  by  designator 

•  All  officers  in  a  command  (UIC)  grouped  by  designator 

•  All  officers  in  alpha  order  in  a  command  and  completed 
modules  grouped  by  designator 

(3)  Queries  common  to  the  program  management  and 

organizational  views 


•  All  classes  delivered  in  the  last  90  days 


b.  Generate  Interactive  Queries  (Process  2.2) 

(1)  Generic  queries 

•  All  course  modules  grouped  by  course  sponsor  (select  on 
course  sponsor  input) 

•  All  course  modules  grouped  by  competency  (select  on 
competency  input) 


(2)  Queries  common  to  the  program  management  and 

enterprise  views 


•  All  officers  in  alpha  order  (select  on  UIC  input) 
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•  All  officers  in  alpha  order  and  completed  modules  (select  on 
UIC  input) 

•  All  course  modules  completed  by  a  specific  officer  (select  on 
SSN  input) 

•  All  officers  based  on  profile  query  requiring  one  or  more  of  the 
following  input: 

Rank 

Service 

Designator 

UIC 

Health  Service  Region 

Course  Module  (or  range  of  modules) 

(3)  Queries  common  to  the  organizational  view  (filter  by  UIC 

Number) 

•  Officers  in  alpha  order  (select  on  designator  input) 

•  Officers  in  alpha  order  (select  on  rank  input) 

•  Officers  in  alpha  order  (select  on  course  module  or  competency 
category  input) 


c.  Generate  Statistical  Reports  (Process  2.3) 

(1)  Generic  queries 

•  The  average  number  of  EME  hours  attained  per  officer 

by:  total  officers,  rank,  designator,  UIC,  and  HSR 

•  The  number  of  officers  that  have  completed  a  specific  course 
(grouped  by  course) 
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by:  total  officers,  rank,  designator,  UIC,  and  HSR 

•  The  number  of  officers  that  have  completed  a  competency 
category  (grouped  by  category) 

by:  total  officers,  rank,  designator,  UIC,  and  HSR 

•  The  percentage  of  officers  that  have  completed  a  specific 
course  (grouped  by  course) 

by:  total  officers,  rank,  designator,  UIC,  and  HSR 

•  The  percentage  of  officers  that  have  completed  a  competency 
category  (grouped  by  category) 

by:  total  officers,  rank,  designator,  UIC,  and  HSR 

•  The  number  of  courses  in  the  EME  curriculum  by  course 
sponsor 

•  The  number  of  hours  provided,  sub-divided  by  sponsor  by: 
fiscal  quarter,  fiscal  year,  and  between  two  dates 

5.  Required  Reports 

The  reports  listed  in  this  section  are  organized  according  the  EMETRAK  process 
model  (Figure  9).  The  report  formats  must  conform  to  the  style  presented  in  the 
Appendix  G.  Structured,  Interactive  and  Statistical  reports  are  listed  in  Tables  8,  9,  and 
10,  respectively.  The  abbreviations  P,  E,  and  O  in  the  tables  correspond  to  the  program 
management,  enterprise,  and  organizational  views. 


a.  Generate  Structured  Reports  (Process  3.1) 

Structured  reports  are  pre-formatted  reports  that  do  not  require  user  input. 


80 


Number 

Report  Name 

Views 

1 

Officers  in  Alphabetical  Order 

P,  E.  0 

2 

Officers  in  Alphabetical  Order  Grouped  by  Designator 

P.  E.  0 

3 

Officers  in  Alphabetical  Order  Grouped  by  Command 

P.  E 

4 

Officers  in  Alphabetical  Order  and  Conripleted  Modules 

P,  E,  0 

5 

Course  Modules  (with  descriptions) 

P,  E,  0 

6 

Competency  Categories 

P,  E,  0 

7 

Course  Modules  by  Competency  Category 

P,  E,  0 

8 

Course  Modules  by  Sponsor 

P.  E,0 

9 

Participating  Commands  (UlC) 

P.  E,  0 

10 

Course  Completion  Letter 

P,  0 

11 

Completion  Certificate 

P,0 

1  12 

Official  Transcript 

P 

Table  8.  Structured  Reports 


b.  Generate  Interactive  Reports  (Process  3.2) 

Interactive  reports  require  user  input  to  determine  selection  criteria  for  the 
data  set  in  the  report. 


Number 

Report  Name 

Views 

13 

Officers  and  Completed  Modules  Grouped  by  Designator 
(input  designator) 

P,  E,  0 

14 

Officers  and  Completed  Modules  Grouped  by  Command 
(input  UlC) 

P,  E 

15 

Officers  and  Completed  Modules  Grouped  by  Rank  (input 
rank) 

P.  E.  0 

16 

Completed  Modules  by  a  Specific  Officer  (input  SSN) 

P,  E,  0 

Table  9.  Interactive  Reports 


c.  Generate  Statistical  Reports  (Process  3.3) 

Statistical  reports  provide  summaries  of  the  data  in  tabular  (T),  line  graph 
(L),  bar  (B),  or  pie  chart  (P)  format.  Appendix  K  provides  examples  of  the  statistical 
format  types. 


81 


Number 

Report  Name 

Views 

Type 

17 

Course  Modules  Provided  in  Last  90  Days 

P,  E,0 

T 

18 

Classes  Provided  in  the  Last  90  Days 

P.  E,0 

T 

19 

Average  EME  hours  attained  per  officer  by:  total 
officers,  rank,  designator,  UlC,  and  HSR 

P,  E 

T/L 

20 

Number  of  officers  that  have  completed  a  specific 
course  (grouped  by  course)  by:  total  officers,  rank, 
designator,  UlC,  and  HSR 

P.  E 

T 

21 

Number  of  officers  that  have  completed  a 
competency  category  (grouped  by  category)  by: 
total  officers,  rank,  designator,  UlC,  and  HSR 

P,  E 

T 

22 

Percentage  of  officers  that  have  completed  a 
specific  course  (grouped  by  course)  by:  total 
officers,  rank,  designator,  UlC,  and  HSR 

P,  E 

P 

23 

Percentage  of  officers  that  have  compieted  a 
competency  category  (grouped  by  category)  by: 
total  officers,  rank,  designator,  UlC,  and  HSR 

P,  E 

P 

24 

Number  of  courses  in  the  EME  curriculum  by 
course  sponsor 

P.  E 

B 

25 

Number  of  hours  in  the  EME  curriculum  by  course 
sponsor 

P,  E 

B 

26 

Number  of  hours  provided,  sub-divided  by  sponsor 
by:  fiscal  quarter,  fiscal  year,  and  between  two 
dates 

P,  E 

T 

Table  10.  Statistical  Reports 


6.  Security  Requirements 

National  Telecommunications  and  Information  Systems  Security  Publication  2 
(1986)  specifies  that  sensitive  but  unclassified  information  must  be  protected  from 
disclosure,  loss,  misuse,  alteration,  or  destruction.  The  EMETRAK  database  contains 
sensitive  but  unclassified  information  protected  under  the  Privacy  Act  of  1974. 
Therefore,  the  EMETRAK  system  must  comply  with  the  security  class  C2  controlled 
access  protection.  [Ref.  13] 

Access  controls  must  be  enforced  at  both  the  client  and  database  server  level. 
Information  security  should  be  enforced  through  the  following  mechanisms: 

•  Discretionary  access  control  -  Define  and  control  access  between  named  users 
and  named  objects  (files,  tables,  forms,  reports,  etc.)  down  to  the  single  user 
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level  in  the  system.  The  enforcement  mechanism  should  be  through  the  use  of 
group  and  user  permissions. 

•  Identification  and  authentication  -  Use  a  protected  mechanism  (log  on  and 
passwords)  to  authenticate  a  user’s  identity.  The  log  on  procedure  should  be 
implemented  in  the  client  application.  Authentication  data  must  be  protected 
from  access  by  unauthorized  users  and  should  be  implemented  in  the  server 
application. 

•  Data  security  -  The  system  must  be  able  to  encrypt  the  officer  SSN,  last  name, 
and  UIC  prior  to  transmission.  This  feature  prevents  name,  SSN,  and  UIC 
association  during  data  transmission  between  the  client  site  and  the  server. 

•  Audit  -  The  system  must  have  a  transaction  tracking  capability  to  audit 
modifications,  insertions,  and  deletions  from  the  database.  Identification  of 
the  time,  date,  user  ID,  and  type  of  transaction  accomplished  is  required. 

7.  Client  Application  Features 

The  client  must  be  a  Windows-based  application  that  is  capable  of  running  on  the 
Windows®  3.11  operating  system  using  a  80386  or  later  version  processor  with  8  MB  of 
RAM.  The  intention  is  to  distribute  run-time  executable  versions  of  the  EMETRAK 
client  via  floppy  disk,  file  transfer  protocol,  or  electronic  mail.  Therefore,  the  client 
must  contain  its  own  set-up  utility. 

The  client  user  interface  should  emulate  the  prototype  application  and  support  a 
local  query  and  report  generation  capability.  The  application  must  support  ANSI  SQL  89 
and  the  Open  Database  Connectivity  (ODBC)  protocol.  Finally,  an  identification  and 
authentication  feature  must  be  incorporated  in  a  log  on  routine. 
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8. 


Database  Server  Application  Features 


Selection  of  the  server  hardware  and  operating  system  will  be  based  on  the  system 
requirements  of  the  database  server  application.  Specific  procurement  recommendations 
for  a  server  and  operating  system  are  beyond  the  scope  of  this  thesis  and  will  not  be 
addressed.  However,  a  server  database  application  should  have  the  following  features: 

•  Support  client  server  computing  over  a  wide  area  network  using  TCP/IP 

•  Must  be  C2  compliant 

•  Allow  16  simultaneous  users 

•  Provide  fine-grained  database  privileges  for  objects,  queries,  and  access 

•  Provide  concurrency  control  through  row  (record)  level  locking 

•  Provide  for  centralized  security  management 

•  Provide  an  adjustable  auditing  capability 

•  Support  stored  procedures  activated  by  client  application  remote  procedure 
calls 

•  Provide  parallel  query  support 

•  Provide  on-line  back-up  capability 

•  Support  job  scheduling  for  reports  and  back-ups 


D.  RECOMMENDATIONS  FOR  THE  REMAINING  SDLC  PHASES 

The  remaining  stages  of  development  for  the  multi-user  system  are  design, 
coding,  testing,  implementation,  and  support.  DMDC  programmers  will  begin  design 
and  coding  once  the  requirements  are  completed.  They  estimate  that  eight  weeks  will  be 
required  to  produce  an  initial  version  of  the  multi-user  system.  Once  the  system  is 
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functional,  it  will  undergo  extensive  system  testing  to  verify  and  validate  the 
requirements. 


1.  System  Testing 

System  testing  will  be  accomplished  in  two  stages:  alpha  and  beta  testing.  Alpha 
testing  involves  reviewing  the  basic  functionality  of  the  system  over  both  types  of 
connection  methods:  TCP/IP  (Internet)  and  PPP  (dial-up).  DMDC  will  provide  a 
functional  client  application  to  the  EME  staff  and  the  EMETRAK  development  team  for 
testing.  Data  will  be  migrated  from  the  single  user  system  to  an  Oracle  Server  7.2 
RDBMS  running  on  a  Sparc  20  workstation  located  at  DMDC  West.  DMDC  has  agreed 
to  maintain  the  database  during  the  entire  testing  period  estimated  to  last  approximately 
six  months.  Five  test  nodes  are  recommended  for  the  alpha  test;  four  at  NPS  and  one  at 
NSHS,  Bethesda.  The  test  nodes  are  the  EME  program  coordinator,  EME  administrative 
support  staff  (2  nodes),  EME  program  manager  at  NSHS,  and  the  EMETRAK 
development  team.  Special  attention  must  be  focused  on  evaluating  system  response  over 
the  wide  area  cormection  during  the  alpha  test.  Recommended  improvements  from  the 
alpha  test  version  should  be  incorporated  prior  to  the  beta  test  stage. 

Beta  testing  should  involve  a  limited  number  of  MTF  sites  to  further  test  system 
functionality  over  the  existing  NMDN  architecture.  During  the  beta  test  stage,  a  decision 
regarding  the  procurement  of  server  hardware,  software,  and  location  will  be  required. 
Further,  system  support  decisions  will  be  required  concerning  database/system 
administration  and  technical  support  personnel  at  that  stage.  Two  goals  of  the  beta  test 
should  be  to  migrate  the  existing  database  from  DMDC  to  an  EMETRAK  server  and  to 
have  an  adequate  technical  support  structure  in  place  before  beginning  system 
installation. 
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2. 


System  Installation 


Two  options  are  provided  for  installation.  One  option  is  the  procurement  of  a 
dedicated  EMETRAK  server  and  another  is  outsourcing  server  support  to  a  DOD 
organization. 

The  dedicated  server  option  requires  a  substantial  capital  expenditure  which  has 
been  planned  and  budgeted.  The  advantage  offered  seems  to  be  increased  management 
control  because  the  EME  program  office  is  taking  ownership  of  the  administration 
process.  The  disadvantage  of  owning  a  dedicated  server  is  the  major  increase  in 
maintenance  and  personnel  costs  over  the  single-user  system.  Training  cost  for  a 
database/systems  administrator  is  another  factor  in  selecting  an  installation  option. 
DMDC  database  administrators  estimate  that  approximately  four  months  of  training  are 
needed  on  Oracle  or  comparable  RDBMS  systems  to  adequately  prepare  a  person  for  the 
database  administrator  position.  Training  for  the  server  operating  system  and  system 
administration  is  also  required.  Developing  and  maintaining  expertise  in  these  areas  will 
require  a  significant  investment  of  time  and  money. 

An  alternative  that  should  be  investigated  is  migrating  the  database  from  DMDC 
to  the  NFS  Oracle  7.3  DBMS  miming  on  the  University’s  Digital  Equipment  Corporation 
(DEC)  Alpha  server.  An  agreement  could  be  arranged  whereby  the  EME  program 
reimburses  NFS  for  data  storage,  computing  support,  and  technical  support  services  for 
the  back-end  server.  Outsourcing  for  service  is  advantageous  because  the  day-to-day  data 
and  system  administration  is  shifted  from  the  program  office  to  the  service  provider. 
Although  further  study  is  required,  this  option  seems  to  offer  a  cost  effective  alternative 
to  procuring  and  maintaining  a  dedicated  server. 
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VII.  SUMMARY 


A.  PROJECT  CONCLUSIONS 


1.  Service-based  Learning 

Service-based  learning  is  a  form  of  job  instruction  training  where  learning  and 
experience  are  gained  while  providing  a  service  [Ref.  14,  pp.  252-253],  It  is  not  as 
narrowly  focused  or  closely  supervised  as  on-the-job-training,  but  it  enables  a  person  to 
thoroughly  explore  a  subject  area  and  then  apply  what  has  been  learned  to  a  project.  The 
EME  program  provided  just  such  an  opportunity. 

The  EMETRAK  project  facilitated  my  development  as  a  systems  analyst  by 
providing  an  opportunity  to  learn  about  design  and  implementation  issues  during  the 
actual  deployment  of  a  system.  Service-based  learning  is  not  appropriate  in  every 
situation,  particularly  when  a  project  is  under  tight  schedule  or  budget  constraints. 
However,  in  the  academic  environment,  service-based  learning  proves  to  be  a  practical 
way  to  provide  experience  for  students  learning  the  role  of  a  systems  analyst. 

This  topic  was  ideal  for  providing  systems  analysis  experience  because  of  its 
scope  and  the  fact  that  each  stage  of  the  SDLC  was  explored.  It  provided  design  as  well 
as  project  management  experience  and  required  knowledge  of  many  different 
technologies.  The  project  required  study  of  process  and  data  modeling  techniques, 
database,  application  and  network  design.  Further,  it  enabled  the  application  of  analysis 
techniques  and  project  management  tools  learned  in  the  Information  Technology 
Management  curriculum  to  a  real  world  example.  Finally,  the  project  required  interaction 
with  program  managers,  the  system  owner,  end-users,  and  programmers  to  successfully 
develop  an  application  that  met  the  requirements  of  the  Navy  Medical  Department. 
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2. 


The  Prototype  System  as  a  Development  Tool 


Prototypes  are  developed  by  programmers  to  solicit  feedback  and  assist  in 
application  and  interface  design.  The  Phase  I  prototype  system  served  this  purpose,  but  it 
was  also  used  as  a  model  for  Phase  II.  Once  the  prototype  application  was  refined,  it 
became  the  vehicle  for  describing  system  requirements  for  programmers  developing  the 
multi-user  version.  Programmers  studied  the  written  specifications  and  then  referred  to 
the  prototype  to  see  the  desired  functionality. 

The  use  of  a  prototype  greatly  streamlined  the  development  process  for  both 
phases  of  EMETRAK.  Access  2.0®  was  an  excellent  prototyping  and  rapid  application 
development  tool.  Speed  of  development  was  extremely  important  in  order  to  meet  the 
initial  project  milestones.  However,  the  prototype  application  proved  to  be  even  more 
effective  when  used  by  the  analyst  to  describe  multi-user  system  requirements. 

3.  System  Owner  and  End-user  Involvement 

This  project  reinforced  the  importance  of  managerial  support  and  end-user 
involvement  to  the  success  of  a  systems  development  effort.  The  ability  to  articulate  the 
benefits  of  the  system  and  demonstrate  a  functional  prototype  after  only  a  few  weeks  of 
programming  helped  garner  crucial  political  and  economic  support  for  the  project  at  a 
time  when  formal  approval  and  project  funding  were  in  doubt.  Moreover,  proving  that 
the  project  was  feasible  established  our  credibility  with  the  system  owner  which  was 
critical  to  sustaining  development  over  the  life  of  the  project. 

Involving  end-users  early  in  development  helped  avoid  potential  problem  areas 
and  allowed  more  detailed  system  specifications  to  be  written.  The  detailed  nature  of  the 
specifications  reduced  the  number  of  changes  and  resulting  delays  during 
implementation.  Further,  end-user  acceptance  was  enhanced  because  they  were  able  to 
gain  first-hand  experience  with  the  application  and  see  the  benefits  as  the  system  was 
being  developed. 
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Management  and  end-user  support  was  enhanced  in  this  project  because  each  was 
closely  involved  in  the  process  and  became  partners  in  system  development. 


4.  Changing  Scope  of  the  Project 

One  of  the  original  research  questions  asked  what  type  of  information  system 
would  support  the  future  needs  of  the  EME  program;  a  single  user  system,  a  multi-user 
system  implemented  over  a  LAN  or  a  multi-user  system  implemented  over  a  WAN?  The 
answer  really  is  all  three.  In  the  early  stages  of  the  project  (FY-95),  a  single  user  system 
was  adequate  to  meet  the  requirements  for  data  collection  and  reporting  for  a  limited 
number  of  participants.  As  the  scope  of  the  EME  program  increased  in  FY-96,  the 
supporting  staff  grew  and  the  number  of  end-users  increased.  A  multi-user  system 
implemented  over  a  LAN  at  NPS  proved  adequate  to  support  administration  of  the 
program.  Remote  access  to  the  database  from  numerous  end-user  sites  is  still  the  desire 
for  FY-97.  While  the  exact  deployment  schedule  of  the  multi-user  system  is  in  question, 
it  will  eventually  be  implemented  over  a  wide  area. 

The  point  is  that  the  scope  of  any  project  will  change  and  must  be  planned  for 
during  development.  In  the  case  of  EMETRAK,  the  fundamental  process  and  data 
models  were  designed  to  be  scaleable.  During  implementation,  the  selection  of  the  client 
server  model  permitted  the  multi-user  system  to  be  implemented  over  either  a  LAN  or 
WAN  as  the  number  of  end-users  and  their  locations  changed. 

The  key  to  success  seems  to  be  understanding  that  the  scope  of  a  project  will 
change  and  then  anticipating  how  the  system  will  be  affected  by  the  change.  This  was 
achieved  in  the  EME  project  through  a  thorough  analysis  of  the  business  problem  and, 
most  importantly,  by  having  a  vision  and  the  support  of  the  program  manager  and  system 
owner. 
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B.  AREAS  FOR  FURTHER  RESEARCH 


1.  Multi-user  System  Installation  and  Support  Issues 

A  significant  number  of  EMETRAK  life  cycle  management  issues  require  further 
study.  Alpha  and  Beta  testing  must  be  concluded  and  the  multi-user  system  must  still  be 
installed  and  supported  in  the  field.  Installation  issues  which  require  further  analysis  are 
selection  of  the  database  server,  NMDN  network  bandwidth  usage,  determining  the 
EMETRAK  deployment  schedule,  and  development  of  a  technical  support  infrastructure. 
System  and  code  maintenance,  client  application  version  control,  database  maintenance, 
and  analysis  of  future  system  requirements  are  system  support  issues  that  should  be 
investigated. 


2.  EMETRAK  Integration  Issues 

EMETRAK  currently  has  a  fairly  narrow  focus,  however,  its  relational 
architecture  makes  it  well  suited  to  handle  other  types  of  data  pertinent  to  the  individual 
officer.  The  system  is  capable  of  tracking  educational  information  from  sources  outside 
of  the  EME  program,  medical  readiness  data,  or  professional  credentials  of  the  Medical 
Department  officer.  Incorporating  this  type  of  information  into  a  central  repository 
warrants  further  study. 

Integration  of  EMETRAK  data  with  other  applications  like  the  Reserve  Training 
and  Readiness  System  (RSTARS),  the  Navy  Integrated  Training  and  Assignment  System 
(NITRAS  Phase  II),  or  the  DOD  integrated  personnel  system  also  have  merit  and  provide 
areas  for  continued  research. 


3,  Application  of  World-Wide  Web  (WWW)  Technologies 

The  recent  explosion  of  Web  technologies  provides  another  avenue  for  delivering 
EME  information  to  the  customer.  Programming  languages  like  Java  allow  the 
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development  of  self-contained  EMETRAK-like  applets  that  can  be  distributed  over  the 
Web.  This  technology  is  advertised  as  providing  platform  independence  (hardware  and 
software)  and  enables  unlimited  distribution  of  the  application  with  minimal  overhead. 
This  type  of  technology  offers  an  exciting  alternative  to  traditional  client  server 
computing  and  will  likely  change  our  inter-networking  paradigms  in  the  future.  Web 
technologies  and  security  issues  should  be  investigated  as  one  possible  future 
implementation  of  the  program. 


4.  Distributed  Database  Technologies 

Applications  like  Lotus  Notes®  have  dramatically  reduced  the  cost  and 
complexity  of  managing  distributed  databases.  Features  that  include  concurrent  access 
controls,  automatic  data  replication,  job  scheduling,  and  fault  tolerance  have  made  it 
popular  with  organizations  operating  in  the  distributed  computing  environment. 
Moreover,  the  ability  to  integrate  data  directly  into  electronic  mail,  word  processing 
documents,  and  other  applications  makes  the  system  all  the  more  appealing.  This  type  of 
technology  is  being  used  by  a  number  of  other  DOD  agencies  and  its  applicability  to  the 
EME  program  and  Navy  Medicine  should  be  researched. 


91 


92 


APPENDIX  A.  INITIAL  USER  QUESTIONNAIRE 


This  appendix  contains  the  questions  that  were  used  during  the  initial  interviews 
with  the  program  manager  and  system  owner  to  define  the  problem  and  limit  its  scope. 
The  general  categories  were  taken  from  Whitten.  [Ref.  5] 


I.  About  the  PEOPLE 

Who  would  be  the  end-users  of  this  system? 

Would  anyone  be  indirectly  affected  by  the  system? 

What  existing  system  is  in  place  (if  any)? 

What  people  or  political  problems,  opportunities,  or  directives  triggered  this  project  request? 

How  will  management  and  users  feel  about  this  project  if  it  is  approved  for  application 
development? 

II.  About  the  DATA 

What  are  the  key  inputs  to  this  system? 

What  are  the  key  outputs  from  this  system? 

Is  any  data  currently  being  captured  and  stored  in  computer  files  and/or  databases? 

III.  About  the  ACTIVITIES 

What  is  the  purpose  or  mission  of  this  business  area  (in  non-computer  terminology)? 

What  are  the  goals  and  objectives  of  this  business  area? 
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Has  any  of  this  system  been  computerized  already? 


IV.  About  the  NETWORKS 


Will  this  project  provide  support  for  multiple  locations?  If  so,  where  are  they? 
How  do  the  locations  currently  communicate? 

Are  any  computer  networks  currently  in  use? 
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APPENDIX  B.  PROPOSED  MTF  DEPLOYMENT  SITES 


This  appendix  lists  the  proposed  deployment  sites  for  the  EMETRAK  multi-user 

system. 


UlC 

ACTIVITY 

STATE 

00162 

NMCL  ANNAPOLIS 

MD 

00267 

NMCL  KEY  WEST 

FL 

48488 

NMCL  KINGS  BAY 

GA 

46491 

NMCL  LONDON 

UK 

66898 

NMCL  NEW  ORLEANS 

LA 

68098 

NMCL  PEARL  HARBOR 

HI 

68101 

NMCL  PHILADELPHIA 

PA 

66099 

NMCL  PORT  HUENEME 

CA 

00105 

NMCL  PORTSMOUTH 

VA 

00231 

NMCL  QUANTICO 

VA 

65575 

NMCL  SEATTLE 

WA 

68349 

REDCOM  16 -MINNEAPOLIS 

MN 

61337 

NH  BEAUFORT 

SC 

00168 

NNMC  BETHESDA 

MD 

68095 

NH  BREMERTON 

WA 

68093 

NH  CAMP  LEJEUNE 

NC 

68094 

NH  CAMP  PENDLETON 

CA 

68084 

NH  CHARLESTON 

SC 

66094 

NH  CHERRY  POINT 

NC 

00285 

NH  CORPUS  CHRISTI 

TX 

00211 

NH  GREAT  LAKES 

IL 

61726 

NH  GROTON 

CT 

68096 

NH  GUAM 

MIC 

61564 

NH  GUANTANAMO 

CU 

00232 

NH  JACKSONVILLE 

FL 

68875 

Inh  KEFLAVIK 

1C 

66095 

NH  LEMOORE 

CA 

68090 

NH  LONG  BEACH 

CA 

60002 

NH  MILLINGTON 

TN 

66096 

NH  NAPLES 

IT 

68086 

NH  NEWPORT 

Rl 

66097 

NH  OAK  HARBOR 

WA 
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UlC  ACTIVITY  STATE 


NH  OAKLAND  CA 

NH  OKINAWA  JA 


NH  ORLANDO  FL 

NH  PATUXENT  RIVER  MD 


00203  NH  PENSACOLA  K 


83  NMC  PORTSMOUTH  VA 


28  NH  ROOSEVELT  ROADS 


66101  NH  ROTA  SP 


NMC  SAN  DIEGO  CA 


NH  SIGONELLA  IT 


NH  TWENTYNINE  PALMS  CA 

NH  YOKOSUKA  JA 


0608A  NNDCBETHESDA  MD 


3  NDC  BREMERTON 
0  NDC  CAMP  LEJEUNE 


62594  NDC  CAMP  PENDLETON  CA 


65999  NDC  CHARLESTON  SC 

68326  NDC  GREAT  LAKES  IL 


62328  NDC  GUAM 


68444  NDC  JACKSONVILLE _ ^ 

62947  NDC  LONG  BEACH  CA 

68442  NDC  NAPLES _ IT_ 

66023  NDC  NEWPORT  Rl 
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APPENDIX  C.  EXISTING  NMDN  NETWORK  TOPOLOGIES 
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Figure  C-1.  North  Atlantic  Metropolitan  Area  Network  (MAN) 


204,34.21,8(252 
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Figure  C-2,  Great  Lakes  Metropolitan  Area  Network  (MAN) 
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Figure  C-3.  Bethesda  Metropolitan  Area  Network  (MAN) 


199,226.5,16(252) _ 
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Figure  C-4.  Mid-Atlantic  Metropolitan  Area  Network  (MAN) 
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Figure  C-5.  Tidewater  Metropolitan  Area  Network  (MAN) 
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Figure  C-6.  South  Atlantic  Metropolitan  Area  Network  (MAN) 
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Figure  C-7.  Gulf  Coast  Metropolitan  Area  Network  (MAIV) 


199.10.188.16(252) 
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Figure  C-8.  Puget  Sound  Metropolitan  Area  Network  (MAN) 


Figure  C-9.  San  Dteg„Mrtr„p„||te„ 


C-10.  Europe  Metropolitan 


APPENDIX  D.  DATA  FLOW  DIAGRAMS 
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Interactive  Query 
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Figure  D-2.  Level  1  Process  2  Chart 
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Figure  D-3.  Level  1  Process  3  Chart 


Figure  D-4.  Level  2  Process  1.1  Chart 
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Figure  D-5.  Level  2  Process  1.2  Chart 
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Figure  D-6.  Level  2  Process  1.3  Chart 


Figure  D-8.  Level  2  Process  1.5.1  Chart 
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Figure  D-10.  Level  2  Process  1.5.3  Chart 
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igureD-11.  Level  2  Process 
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APPENDIX  E.  PROTOTYPE  DATA  DICTIONARY 


This  appendix  lists  all  of  the  data  elements  in  the  EMETRAK  prototype  system 
by  table  and  field  name. 


Data  Item 

Table  Name 

Field  Name 

Type 

Size 

Index 

1 

CLASS 

ClassState 

Text 

2 

2 

CLASS 

SSN 

Text 

11 

PrimaryKey 

3 

CLASS 

ClassZip 

Text 

id 

4 

CLASS 

ClassCity 

Text 

25 

5 

CLASS 

ClassStreet 

Text 

35 

6 

CLASS 

HostCommand 

text 

35 

7 

CLASS 

Instructor 

Text 

25 

8 

CLASS 

ClassDate 

Date/Time 

8 

9 

CLASS 

CourselD 

Text 

6 

PrimaryKey 

10 

CLASS 

Form  Letter 

Yes/No 

1 

11 

COMPCOURSE 

Competency 

Text 

50 

PrimaryKey 

12 

COMPCOURSE 

CourselD 

Text 

6 

PrimaryKey 

13 

COMPETENCYCAT 

Competency 

Text 

50 

14 

COURSE 

CourseName 

Text 

100 

15 

COURSE 

CourseSponsor 

Text 

50 

16 

COURSE 

EMEProgInfo 

Number  (Integer) 

2 

17 

COURSE 

CourseDescription 

Memo 

- 

18 

COURSE 

Hours 

Number  (Double) 

8 

19 

COURSE 

CourselD 

Text 

6 

PrimaryKey 

20 

COURSE 

CEUCredits 

Number  (Double) 

8 

21 

em'eproginfo 

EMEProgOffPhone 

Text 

13 

22 

EMEPROGINFO 

EMEDSNPhone 

Text 

8 

23 

EMEPROGINFO 

EMEProgInfo 

Number  (Integer) 

2 

PrimaryKey 

24 

EMEPROGINFO 

ProgCoordLName 

Text 

25 

25 

EMEPROGINFO 

ProgCoordFName 

Text 

15 

26 

EMEPROGINFO 

ProgCoordMInit 

Text 

1 

27 

EMEPROGINFO 

ProgCoordTItlel 

Text 

10 

28 

EMEPROGINFO 

ProgCoordTitle2 

Text 

35 

29 

EMEPROGINFO 

ProgCoordTitle3 

Text 

25 

30 

EMEPROGINFO 

NPSDeptName 

Text 

50 

31 

LISTOFREPORTS 

ReportName 

Text 

50 

32 

LISTOFREPORTS 

ReportNumber 

Number  (Integer) 

2 

34 

OFFICER 

SSN 

text 

11 

PrimaryKey 

35 

OFFICER 

Email 

Text 

25 

36 

OFFICER 

JobTitle 

Text 

50 

37 

OFFICER 

SubSpecialty 

Text 

6 

38 

OFFICER 

Designator 

Text 

5 
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39 

OFFICER 

BSC 

Text 

6 

40 

OFFICER 

Service 

Text 

4 

41 

OFFICER 

Rank 

Text 

4 

42 

OFFICER 

Minitlal 

Text 

1 

43 

OFFICER 

FirstName 

Text 

15 

44 

OFFICER 

LastName 

Text 

25 

45 

OFFICER 

UlC 

6 

46 

UlC 

UICName 

45 

47 

UlC 

HealthSvcRegion 

Number  (Integer) 

2 

48 

UlC 

UlCType 

Text 

1 

49 

UlC 

UlCFax 

Text 

13 

50 

UlC 

UlCDSNPhone 

Text 

7 

51 

UlC 

UlCPhone 

Text 

13 

52 

UICZip 

Text 

10 

53 

UlC 

UlCState 

Text 

2 

54 

UlC 

UlCStreet 

Text 

30 

55 

UlCTitle 

50 

56 

UlC 

6 

PrimaryKey 

57 

UlC'City 

Text 

25 
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APPENDIX  F.  PROTOTYPE  SYSTEM  QUERIES 


This  section  describes  the  significant  system  queries  written  for  the  EMETRAK 
prototype  system.  The  queries  were  written  in  the  MS  Access  version  of  SQL  which  is 
slightly  different  than  the  ANSI  standard. 

1.  qryOfficers  by  Alpha 

This  query  lists  the  officers  in  the  database  in  alphabetical  order.  The  result  is 
ordered  by  last  name  then  first  name. 


SELECT  DISTINCTROW  OFFICER.SSN,  OFFICER.LastName,  OFFICER.FirstName, 
OFFICER.Minitial,  OFFICER.Rank,  OFFICER.BSC,  OFFICER.Designator, 

OFFICER.  SubSpecialty,  OFFICER.JobTitle,  OFFICER.Email,  OFFICER.UIC, 
UIC.UICName,  UIC.UICStreet,  UIC.UICCity,  UIC.UICState,  UIC.UICZip, 
UIC.UICPhone,  UIC.UICDSNPhone 

FROM  UIC  INNER  JOIN  OFFICER  ON  UIC.UIC  =  OFFICER.UIC 
ORDER  BY  OFFICER.LastName,  OFFICER.FirstName; 


2.  qryOfficersbyUIC 


This  query  lists  the  officers  in  the  database  in  alphabetical  order  grouped  by 
command  and  health  service  region. 


SELECT  DISTINCTROW  UIC.UICName,  UIC.UICState,  UIC.HealthSvcRegion 
OFFICER.* 

FROM  UIC  INNER  JOIN  OFFICER  ON  UIC.UIC  =  OFFICER.UIC 
ORDER  BY  UIC.HealthSvcRegion,  OFFICER. LastName; 
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3.  qryEMELongCourses 


This  query  lists  all  full-length  courses  in  the  EME  program  syllabus  ordered  by 
course  ID  number. 


SELECT  DISTINCTROW  COURSE.CourselD,  COURSE.CourseName, 
COURSE.CourseDescription,  COURSE.Hours,  COURSE.CourseSponsor 
FROM  COURSE 

WHERE  ((COURSE.CourselD  Not  Like  "*a")) 

ORDER  BY  COURSE.CourselD; 


4.  qryClassLast90Days 


This  query  lists  all  classes  completed  in  the  last  90  days  ordered  by  class  date, 
course  ID  number,  and  officer’s  last  name. 


SELECT  DISTINCTROW  CLASS. ClassDate,  CLASS.CourselD, 
COURSE.CourseName,  OFFICER.LastName,  OFFICER.FirstName,  OFFICER.Minitial, 
OFFICER.Rank,  OFFICER.Designator,  CLASS.SSN,  OFFICER.JobTitle, 
OFFICER.UIC,  CLASS.Instructor,  COURSE.Hours,  CLASS.HostCommand, 
CLASS.ClassStreet,  CLASS.ClassCity,  CLASS.ClassState,  CLASS.ClassZip 
FROM  COURSE  INNER  JOIN  (OFFICER  INNER  JOIN  CLASS  ON  OFFICER.SSN  = 
CLASS.SSN)  ON  COURSE.CourselD  =  CLASS.CourselD 
WHERE  ((CLASS. ClassDate>Date()-90)) 

ORDER  BY  CLASS.ClassDate,  CLASS.CourselD,  OFFICER.LastName, 
OFFICER.FirstName; 


5.  qryClassDateName 


This  query  lists  the  classes  completed  by  a  specific  officer  based  on  last  name  or 
SSN  input. 


SELECT  DISTINCTROW  OFFICER.SSN,  OFFICER.LastName,  OFFICER.FirstName, 
OFFICER.Minitial,  OFFICER.Rank,  COURSE.CourselD,  CLASS.ClassDate, 
COURSE.CourseName,  OFFICER.UIC 
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FROM  COURSE  INNER  JOIN  (OFFICER  INNER  JOIN  CLASS  ON  OFFICER.SSN  = 
CLASS.SSN)  ON  COURSE.CourselD  =  CLASS.CourselD 

WHERE  ((OFFICER.SSN  Like  InputBox$("Enter  the  Officer's  SSN  or  Press  Enter  for 
Name  Only  Search","SSN","")  &  "*")  AND  (OFFICER.LastName  Like 
InputBox$("Enter  the  Officer's  Name  or  Press  Enter  for  a  SSN  Search", "Officer 
Name","")&  "*")) 

ORDER  BY  OFFICER.LastName,  OFFICER.FirstName; 


6.  qryCoursesbyCompetency 


This  query  lists  all  EME  courses  grouped  by  competency  category. 


SELECT  DISTINCTROW  COMPCOURSE.Competency,  COURSE.CourselD, 
COURSE.CourseName,  COURSE.Hours 

FROM  COURSE  INNER  JOIN  COMPCOURSE  ON  COURSE.CourselD  = 
COMPCOURSE.CourselD 

GROUP  BY  COMPCOURSE.Competency,  COURSE.CourselD, 
COURSE.CourseName,  COURSE.Hours 
HAVING  ((COURSE.CourselD  Not  Like  "*a")) 

ORDER  BY  COURSE.CourselD; 


7.  qryCompletedModulesbyOfficer 

This  query  provides  a  comprehensive  listing  of  all  officers  in  the  database  and  the 
EME  courses  that  they  have  completed.  The  results  are  ordered  by  last  name  and  course 
ID  number. 


SELECT  DISTINCTROW  OFFICER.*,  CLASS.*,  COURSE.*,  UIC.* 

FROM  COURSE  INNER  JOIN  ((UIC  INNER  JOIN  OFFICER  ON  UIC.UIC  = 
OFFICER.UIC)  INNER  JOIN  CLASS  ON  OFFICER.SSN  =  CLASS.SSN)  ON 
COURSE.CourselD  =  CLASS.CourselD 

WHERE  ((OFFICER.LastName  Like  InputBox$("Enter  a  Last  Name  or  Press  Enter  for 
all  Officers", "Officer  Name","")  &  "*")) 

ORDER  BY  OFFICER.LastName,  OFFICER.FirstName,  OFFICER.Minitial, 

CLASS.  CourselD ; 
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8.  qryProfiler 


This  query  selects  the  record  set  based  on  user  input.  The  result  is  a  list  of 
officers  that  are  of  a  certain  rank  and  designator,  in  a  specific  HSR,  and  have  completed  a 
specific  course  module. 


SELECT  DISTINCTROW  UIC.*,  OFFICER.*,  CLASS.*,  COURSE.* 

FROM  COURSE  INNER  JOIN  (UIC  INNER  JOIN  (OFFICER  INNER  JOIN  CLASS 
ON  OFFICER.SSN  =  CLASS.SSN)  ON  UIC.UIC  =  OFFICER.UIC)  ON 
COURSE.  CourselD  =  CLASS.CourselD 
WHERE  ((CLASS.CourseID=[Forms]! [Profiler]! [Module]))  OR 
((OFFICER.Rank=[Forms] !  [Profiler] !  [Rank]))  OR 
((UIC.HealthSvcRegion=[Forms] ! [Profiler] !  [HSR]))  OR 
((OFFICER.Designator=[Forms]  I  [Profiler]  I  [Designator])) 

ORDER  BY  OFFICER.LastName,  OFFICER.FirstName; 


9.  qryCommands 

The  query  results  in  a  listing  of  all  MTFs  in  the  database. 


SELECT  DISTINCTROW  UIC.* 
FROM  UIC; 

10.  qryClassCourse 


This  query  lists  course  modules  completed  by  an  officer  in  course  ID  order  for 
display  on  the  Officer  Record  subform. 


SELECT  DISTINCTROW  CLASS.SSN,  CLASS.CIassDate,  COURSE.CourselD, 
COURSE.CourseName,  COURSE.Hours,  COURSE.CEUCredits, 

COURSE.  CourseSponsor,  COURSE.CourseDescription,  CL  ASS. Instructor, 
CLASS.HostCommand,  CLASS.ClassStreet,  CLASS.ClassCity,  CLASS.CIassState, 
CLASS.CIassZip 

FROM  COURSE  INNER  JOIN  CLASS  ON  COURSE.CourselD  =  CLASS.CourselD 
ORDER  BY  COURSE.CourselD; 
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11.  qryCompetencyCount 


This  query  totals  the  number  of  courses  and  hours  completed  for  display  on  the 
competency  count  subform. 


SELECT  DISTINCTROW  COMPCOURSE.Competency,  CLASS. SSN, 
Count(COURSE.CourselD)  AS  HowManyCourses,  Sum(COURSE.Hours)  AS 
TotalHours 

FROM  (COURSE  INNER  JOIN  CLASS  ON  COURSE.CourselD  -  CLASS.CourselD) 
INNER  JOIN  (COMPETENCYCAT  INNER  JOIN  COMPCOURSE  ON 
COMPETENCYCAT.Competency  =  COMPCOURSE.Competency)  ON 
COURSE.CourselD  =  COMPCOURSE.CourselD 
GROUP  BY  COMPCOURSE.Competency,  CLASS. SSN 
ORDER  BY  CLASS.SSN; 


12.  qryEMEShortCourses 


This  query  lists  abbreviated  courses  in  the  EME  syllabus  ordered  by  course  ID 
number. 


SELECT  DISTINCTROW  COURSE.CourselD,  COURSE.CourseName, 

COURSE.Hours 

FROM  COURSE 

WHERE  ((COURSE.CourselD  Like  "*a")) 

ORDER  BY  COURSE.CourselD; 


13.  qryOfficersbyCourselD 


This  query  lists  the  officers  that  have  completed  a  particular  course  based  on  the 
course  ID  number  selected. 


SELECT  DISTINCTROW  CLASS.SSN,  OFFICER.LastName,  OFFICER.UIC 
FROM  OFFICER  INNER  JOIN  CLASS  ON  OFFICER.SSN  =  CLASS.SSN 
WHERE  ((CLASS.CourselD  Like  InputBox$("Enter  a  Course  ID 
Number", "CourselD"))); 
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14.  qryWholeEnchilada 


This  query  lists  all  of  the  data  pertinent  to  officers  in  the  database  based  on  UIC 
number  or  UIC  name  input. 


SELECT  DISTINCTROW  UIC.*,  OFFICER.*,  CLASS.*,  COURSE.*, 
COMPETENCYCAT.*,  COMPCOURSE.*,  COMPCOURSE.* 

FROM  (COURSE  INNER  JOIN  ((UIC  INNER  JOIN  OFFICER  ON  UIC.UIC  = 
OFFICER.UIC)  INNER  JOIN  CLASS  ON  OFFICER.SSN  =  CLASS.SSN)  ON 
COURSE.CourselD  =  CLASS.CourselD)  INNER  JOIN  (COMPETENCYCAT  INNER 
JOIN  COMPCOURSE  ON  COMPETENCYCAT.Competency  = 
COMPCOURSE.Competency)  ON  COURSE.CourselD  =  COMPCOURSE.CourselD 
WHERE  ((UIC.UIC  Like  InputBox$("Enter  a  Specific  UIC  or  Press  Enter  for  all 
Commands", "Command  Name","")  &  "*")) 

ORDER  BY  UIC.UICName,  OFFICER.LastName,  OFFICER.FirstName, 
CLASS.CourselD; 
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APPENDIX  G.  PROTOTYPE  SYSTEM  REPORTS 


This  appendix  describes  the  pre-formatted  reports  currently  available  in  the 
EMETRAK  prototype  system. 


1.  Officers  in  Alphabetical  Order  (Figure  G-1) 

This  report  provides  a  listing  of  all  officers  in  the  database  in  alphabetical  order. 
The  report  prints  the  officer’s  SSN,  Name,  Rank,  Billet  Sequence  Code,  Designator,  Sub¬ 
specialty  Code,  Job  Title,  and  UIC  Name  fields.  The  report  is  designed  for  program 
administration  purposes  in  order  to  verify  basic  officer  information  contained  in  the 
database. 

2.  Officers  by  UIC  (Figure  G-2) 

This  report  lists  all  of  the  officers  in  the  database  grouped  by  major  command. 
The  officers  appear  in  alphabetical  order  under  the  appropriate  command  sub-head.  The 
report  is  designed  for  program  administration  purposes  to  verify  officer  location  and  billet 
status. 

3.  List  of  EME  Courses  (Figure  G-3) 

This  report  lists  all  course  modules  available  in  the  EME  curriculum.  The  courses 
are  ordered  by  course  ID  number.  Course  number,  course  title,  course  description,  hours 
and  course  sponsor  are  printed  in  the  body  of  the  report.  The  total  curriculum  hours  are 
summed  at  the  end  of  the  report.  This  report  is  designed  for  distribution  as  an 
abbreviated  course  catalog. 
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4. 


90-Day  Class  Report  (Figure  G-4) 


The  90-day  Class  Report  is  a  listing  of  all  course  modules  provided  by  the  EME 
staff  in  the  preceding  ninety  day  period.  The  report  lists  all  courses,  the  dates  provided, 
and  the  officers  that  received  the  instruction.  The  report  is  designed  as  a  program 
management  tool  to  validate  the  course  delivery  schedule  and  verify  data  entry. 


5.  Detailed  Report  in  Alphabetical  Order  (Figure  G-5) 

The  detailed  report  lists  all  of  the  courses  and  hours  completed  by  an  individual 
officer  based  on  the  name  or  SSN  input  by  the  end-user.  It  is  designed  as  an  unofficial 
transcript  for  distribution  to  participating  officers  upon  request. 


6.  Courses  by  Competency  (Figure  G-6) 

This  report  lists  EME  courses  grouped  according  to  the  DOD  competency 

category.  The  course  ID  number,  course  title,  and  hours  are  listed  in  course  number 
order. 


7.  Detailed  Report  in  Command  Order  (Figure  G-7) 

This  report  is  similar  to  the  previously  mentioned  “alphabetical  order  detailed 
report’,  except  that  the  officers  are  grouped  by  command.  The  report  will  list  a  specific 
officer  based  on  end-user  selection  or  list  all  officers  in  the  database.  It  is  intended  to 
provide  a  comprehensive  listing  of  officers  and  their  program  history  as  a  back-up  paper 
record. 
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8. 


Profiler  (Figure  G-8) 


The  Profiler  is  an  ad  hoc  report  that  allows  the  end-user  to  specify  certain 
selection  criteria.  The  user  may  choose  the  Designator,  Rank,  HSR,  and  Course  ID  of 
interest.  In  return,  the  report  lists  the  officers  in  alphabetical  order  that  meet  the 
particular  profile. 


9.  List  of  Commands  (Figure  G-9) 

This  report  provides  information  about  the  commands  in  the  database.  The 
command  UIC,  command  name,  mailing  address,  telephone  number,  and  HSR  are  listed. 


10.  Course  Completion  Letter  (Figure  G-10) 

This  report  provides  formal  documentation  about  EME  courses  completed  by  an 
individual  officer.  The  letters  are  generated  soon  after  course  completion  information  is 
entered  into  the  database.  The  report  is  in  standard  naval  letter  format  printed  for  the 
program  coordinator’s  signature. 


10.  Completion  Certificate  (Figure  G-11) 

This  report  is  a  completion  certificate  that  shows  the  number  of  CEU  credits 
earned  by  the  officer  during  a  given  period.  The  report  is  printed  on  color  certificate 
paper  and  totals  the  number  of  CEU  hours  earned  since  the  last  certificate  was  issued. 
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Figure  G-1 
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CO 


List  of  EME  Courses 


Effective  Information  Systems 


Figure  G-4 
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Courses  by  Competency 

Competency:  Acquisition  Process 

Course  ID  Course  Name 

38  Defense  Acquisition  Process  and  Health  Care  Implications 

Competency:  Alternative  Health  Care  Delivery  Systems 

Course  ID  Course  Name 

23  Alternative  Health  Care  Delivery  Systems 

Competency:  Communication 


Course  ID  Course  Name 

1  Understanding  and  Effectively  Using  Communication  Media 

2  Communication  Vision  and  Change  in  a  Complex  System 

3  Empowering  Associates  Through  Strategic  Feedback 

4  Bottom-Line  and  High  Impact  Health  Care  Communications 

5  Listening  for  Success 

6  Meeting  Management 

47  Working  in  Teams 


Competency:  Conflict  Resolution 

Course  ID  Course  Name 

44  Labor/Managment  Relations/Negotiation  in  Health  Care 

48  Conflict  Management  and  Negotiation 


08-Apr-96 
Page:  1 
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Figure  G-6 
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List  of  Commands 


49871  HLTHCARE  SUPPO  JAX  DET  MIL 


08  April  1996 


From: 

To: 


Executive  Director,  Institute  for  Defense  Education 
LCDR  Paul  Desmond,  012-38-4000 


and  Analysis,  Navai  Postgraduate  School 


Subj:  EXECUTIVE  MANAGEMENT  EDUCATION  PROGRAM  MODULE  COMPLETION 


w  T'u  certifies  that  you  have  completed  the  requirements 
part  of  the  Executive  Management  Education  Program: 


for  the  following  course  module(s)  as 


Number  Course  Title 


Leadership  and  Motivation 

Class  Date:  7/27/95  Location:  Camp  Lejeune,  NC 


Instructor  Hours 

Crawford  6.00 


.  Questions  concerning  module  completion  should  be  directed  to  the  EME  Program  Staff  at  the 
va  os  graduate  School,  commercial  telephone  (408)  656-2792  or  DSN  878-2792. 


S.  R.  Lamar,  Ph.D. 
CAPT,  MSC,  USN  (Ret) 


Figure  G-10 
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Figure  G-1 1 
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APPENDIX  H.  PROTOTYPE  SYSTEM  FUNCTIONS 


This  section  contains  Access  Basic  code  for  two  of  the  major  system  functions 
that  reside  in  the  prototype’s  module  container.  Additional  coding  was  required  to 
achieve  the  desired  functionality,  however,  it  was  written  as  code  behind  the  form  (CBF) 
and  is  not  included  in  this  section.  The  functions  were  modified  from  examples  listed  in 
Reference  15. 


Function  AutoExec  ()  This  function  sets  global  properties  for  the  prototype 

'  application  and  takes  the  user  to  the  Officer  Record  form 
'  when  the  application  file  is  opened. 

Const  AWINDOWMENU  =  4 
Const  A  MIDE  =  3 

On  Error  GoTo  AutoExec  Err 

Dim  dbCurrent  As  Database 
Dim  rstPreload  As  Recordset 
Dim  intPreload  As  Integer 
Dim  varRet  As  Variant 

DoCmd  Hourglass  True 

Application.SetOption  "Built-In  Toolbars  Available",  False 

If  Not  SysCmd(SYSCMD_RUNTIME)  Then 
DoCmd  SelectObject  A_MACRO,  "AutoExec",  True 
DoCmd  DoMenuItem  A  FORMBAR,  A_WINDOWMENU,  A_HIDE 
DoCmd  OpenForm  "frmSplash" 

DoEvents 
End  If 

Set  dbCurrent  =  DBEngine.  Workspaces(0).Databases(0) 

Set  rstPreload  =  dbCurrent.OpenRecordset("qryPreload",  DB_OPEN_SNAPSHOT) 

rstPreload.MoveLast 

intPreload  =  rstPreload.RecordCount 

varRet  =  SysCmd(SYSCMD_INITMETER,  "EMETRAK  is  initializing...",  intPreload) 
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intPreload  =  1 


rstPreload.MoveF  irst 
Do  Until  rstPreload.EOF 

DoCmd  OpenForm  rstPreload![FormName], , , , ,  A_HIDDEN 
varRet  =  SysCmd(SYSCMD_UPDATEMETER,  intPreload) 
intPreload  =  intPreload  +  1 
rstPreload.MoveNext 
Loop 

DoCmd  Close 

DoCmd  OpenForm  "OfficerRecord" 

AutoExecExit: 

rstPreload.Close 

varRet  =  SysCmd(SYSCMD_REMOVEMETER) 

DoCmd  Hourglass  False 
Exit  Function 

AutoExec_Err: 

MsgBox  "Error"  Err  &  &  Error$,  0,  "AutoExec" 

Resume  AutoExec  Exit 

End  Function 

Function  QuitandExit_Click  Q  'This  function  resets  normal  Access  properties 

'upon  exit  from  the  prototype  application. 

On  Error  GoTo  Err_QuitandExit_Click 

Application.SetOption  "Built-in  Toolbars  Available",  True 
DoCmd  Quit 


ExitQuitandExitClick: 

Exit  Function 

ErrQuitandExitClick : 

MsgBox  Errors 

Resume  Exit  QuitandExit  Click 
End  Function 
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APPENDIX  1.  PROTOTYPE  SYSTEM  USER’S  GUIDE 


A.  INTRODUCTION 

EMETRAK  is  a  powerful,  yet  easy  to  use  windows-based  database  application. 
The  application  is  designed  to  collect,  maintain,  and  report  EME  program  information 
and  it  accomplishes  each  of  those  functions  with  a  minimum  of  key  strokes  or  “clicks”  of 
the  mouse.  EMETRAK  has  a  simple  graphical  user  interface  and  uses  the  “point  and 
click  method  for  navigating  within  the  database  environment.  A  basic  understanding  of 
the  Windows  3.0®  or  higher  operating  system  is  required  and  assumed  as  a  starting  point 
for  using  the  EMETRAK  system.  EMETRAK  is  a  Microsoft  Access  2.0®-developed 
database  application  and  therefore  must  be  operated  from  within  the  Access  application 
environment. 


B.  LAUNCHING  THE  EMETRAK  APPLICATION 


From  Windows  start  Microsoft  Access  2.0  by  double-clicking  on  the  Access  2.0 
icon.  Once  inside  the  Access  application  environment,  open  the  EMETRAK  application 
by  clicking  on  the  open  folder  icon  or  choosing  “Open  Database...  ”  from  the  “File” 
pull-down  menu  and  selecting  the  EMETRAK  application  file  (emetrak.mdb)  from  the 
appropriate  directory  (Figure  I-l).  Double  clicking  on  the  file  name  (emetrak.mdb)  or 
selecting  the  file  and  choosing  OK  will  automatically  launch  the  application. 


Figure  I-l.  Open  Database  Window 

It  normally  takes  several  seconds  for  the  application  files  to  initialize  and  open. 
The  EMETRAK  application  centers  around  the  participating  officer  and,  consequently, 
opens  to  the  Officer  Record  form  (Figure  1-2)  as  the  main  input  screen. 
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c. 


WORKING  WITH  THE  OFFICER  RECORD  FORM 


The  Officer  Record  form  serves  as  an  interface  between  the  system  user  and  the 
data  stored  in  the  application’s  database  tables.  Let’s  take  a  moment  to  navigate  around 
the  form. 

There  are  several  fields  (or  windows)  on  the  form  that  contain  information  about 
the  officer.  The  fields  are: 


•  SSN  The  officer’s  social  security  number 

•  Name  The  officer’s  name  (Last  name  ,  first  name  ,  middle  initial) 

•  Rank  The  officer’s  rank  (e.g.  LCDR,  CDR,  etc.) 

•  Service  USN,  USA,  USAF,  (USNR,  etc.  for  reserve  officers) 


jciass  Date 

Course  ID 

Course  Name 

Hours  CEU  Credits 

Spons( 

i| 

1 

6/29/35| 

6 

1  40D| 

m^m 

1 

1/1/951 

9 

Stakeholder  Management  and  Mapping  the  Health  Care 

1  8.00| 

[21311 

1 

9A 

Stakeholder  Management  and  Mapping  the  Health  Care 

■■EEEl 

12133 

1 

|BQg|g| 

Total  Quality  Leadership -The  Application 

12133 

1 

l■HDii  : 

18 

Effective  Information  Systems 

1  400| 

12131 

El 

m 

3 

)esss& 

Figure  1-2.  Officer  Record  Form 


•  Desig  The  officer’s  designator  or  specialty  code  (2100  -  Medical  Corps 
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(doctor),  2200  -  Dental  Corps  (dentist),  2300  -  Medical 
Service  Corps  (health  care  administrators,  etc.),  and  2900  - 
Nurse  Corps  (nurses)) 

•  Sub-Spec 

The  officer’s  sub-specialty  code  (a  four  or  five  digit  alpha¬ 
numeric) 

•  BSC 

The  officer’s  billet  sequence  code  (The  officer’s  job  line 
number) 

•  Job  Title 

The  officer’s  English  job  title  description. 

UIC 

The  unit  identification  code  (a  five  or  six  digit  alpha¬ 
numeric)  to  which  the  officer  is  assigned. 

•  Email 

The  officer’s  current  electronic  mail  address 

The  rank,  service,  and  UIC  fields  are  drop-down  “pick”  lists  which  make  updating 
the  field  very  easy.  Simply  click  on  the  arrow  next  to  the  desired  field  and  a  list  of 
choices  drop  down.  Select  the  appropriate  choice  and  the  field  is  automatically  updated. 
Note:  Information  in  these  fields  can  be  entered  through  the  keyboard  as  well  as  selecting 
from  the  “pick”  list.  You  should  save  the  record  after  modification  to  ensure  that  the 
database  will  be  updated. 

There  are  several  “action  buttons”  on  the  Officer  Record  form.  Each  button 
performs  a  specific  function  or  displays  information  from  the  database  tables. 


- 1  The  “Display  UIC”  button  (next  to  the  UIC  field)  displays  the  officer’s 

unit  mailing  address  and  unit  telephone  nximber  when  it  is  clicked.  Information  on  this 
pop-up  form  is  read  only  and  can  not  be  modified  from  this  form.  Modifications  to  this 
information  will  be  discussed  in  a  later  section. 


The  group  of  buttons  on  the  right  side  of  the  Officer  Record  form  allows  the  user 
to  navigate  from  one  officer  record  to  another  and  perform  basic  file  operations. 


The  “Add  Officer”  button  allows  the  user  to  enter  a  new  officer  record.  When  it 


is  clicked,  all  of  the  fields  on  the  current  Officer  Record  form  clear  and  are  ready  for  new 
information  to  be  entered.  An  alternate  method  of  adding  a  new  officer  record  is  through 
the  “New”  sub-menu  under  the  “Records”  pull-down  menu. 


m 


5? 


The  “Save”  button  writes  (or  saves)  the  newly  added  or  modified  information  to 
the  database.  Note:  If  the  save  button  is  not  clicked  after  information  on  the  form  has 


145 


been  modified,  the  new  items  will  not  be  added  to  database.  An  alternate  method  of 
saving  a  newly  added  record  is  through  “Save  Record”  under  the  “File”  pull-down  menu. 


L---J  The  “Search”  button  uses  the  standard  Windows  “Find”  flmction.  First,  click  on 
the  desired  field  to  search.  Then  click  the  ’’Search”  button.  The  button  opens  the 
Windows  “Find”  dialog  box  (Figure  1-3). 


Find  What 

Where: 
Search  bi- 


111-11-1111 


Match  Whole  Field 


Q  -itDirectioa- 


O  Currant  Field  #  AH  Fields 


®  Hcmm 


r  Mahii  j2ase 


W  Search  Fields  as  Farmatted 


Find  First 


Eind 


Close 


Figure  1-3.  Find  Input  Box 

Once  in  the  “Find”  dialog  box,  enter  the  string  of  letters  or  numbers  as  required  in 
the  “Find  What”  field  (such  as  the  SSN  111-1 1-1111  depicted  in  the  figure)  and  select  the 
“Find  Firsf’  button  to  initiate  a  search  for  the  appropriate  record.  Close  the  “Find”  dialog 
box  once  the  search  has  found  the  appropriate  record. 

The  “Find”  function  can  also  be  selected  through  the  application  menu  structure 
by  choosing  “Edit”  and  ‘Find”.  Note:  The  “Find”  dialog  box  will  retain  the  data  entered 
until  you  exit  the  application  even  if  the  dialog  is  closed  and  later  reopened. 


The  “Delete”  button  is  used  to  remove  an  officer  record  that  has  been  incorrectly 
entered.  Note:  If  an  officer  record  exists  in  the  database  and  has  classes  assigned  to  it,  the 
application’s  database  integrity  rules  will  prevent  deletion  of  that  officer  record. 


The  “Navigation  Arrows”  allow  the  user  to  move  from  one  record  to  the 
next.  The  officer  records  are  ordered  in  ascending  (least  to  greatest)  order  by  SSN  as  a 
default.  The  records  can  be  re-arranged  in  alphabetical  order  by  last  name  as  specified  by 
the  user.  To  arrange  the  officers  in  alphabetical  order  click  on  the  desired  field  (last 
name),  then  select  “Ascending”  from  the  “Quick  Sort”  sub-menu  under  “Records“  pull¬ 
down  menu. 


The  buttons  arranged  along  the  middle  of  the  Officer  Record  form  allow  the  user 
to  access  other  program  information  related  to  the  Officer  Record  form. 
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D.  ADDING  A  CLASS 

Using  the  “Add  New  Class”  form  is  the  only  way  to  add  a  new  class  occurrence 

to  an  officer’s  record.  Clicking  on  the  button  opens  the  “Add  New  Class” 

form  (Figure  1-5). 
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Figure  1-5.  Add  New  Class  Form 


To  add  a  new  class,  click  on  the  “Add”  button  L— -J  and  all  of  the  form’s  data 
fields  will  clear.  Click  on  the  SSN  field,  type  the  officer’s  SSN,  and  press  enter.  The 
officer’s  name  will  automatically  appear  next  to  the  Name:  label  if  the  SSN  has  been 
entered  correctly.  The  user  jumps  to  the  next  field  by  pressing  enter  after  typing  in  the 
information. 


The  course  text  box  uses  a  “pick”  list  which,  when  selected,  shows  all  of  the  EME 
course  modules.  Course  modules  may  be  entered  by  selecting  the  appropriate  entry  from 
the  “pick”  list  or  by  typing  the  number  in  the  text  box. 


For  multiple  class  entries,  such  as  from  a  course  completion  roster,  the  user  can 
easily  enter  information  on  many  officers  right  from  the  same  “Add  a  Class”  form.  The 
user  simply  enters  a  new  SSN  and  course  number  and  then  double  clicks  in  the  other 
fields  on  the  form  to  paste  the  previously  entered  information  in  the  appropriate  text  box. 
This  method  significantly  speeds  up  class  roster  data  entry. 


To  delete  an  incorrect  entry  use  the  “Delete”  button 
correct  information. 


and  re-enter  the 


The  “Close”  button 


returns  the  user  to  the  Officer  Record  form. 
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E. 


SYSTEM  TABLES 


Clicking  the 


Tables 


Switchboard  (Figure  1-6). 


button  on  the  Officer  Record  form  opens  the  Table 


Fdnh^TableSi^ 


Course 


Competencies 


Figure  1-6.  Table  Switchboard 

Selecting  any  of  the  three  buttons  (Course,  Competencies,  or  UIC)  opens  the 
appropriate  database  table.  Information  in  each  the  database  table  (Figure  1-7)  may  be 
added,  modified  or  deleted  subject  to  the  application  database  integrity  rules. 


a 

Course  ID 

CburseName .  I’Bburs  t 

M . 

Understanding  and  Effectively  Using  Comrr; 

AM 

AW\  NPS 

2 

Con^fiiunication  Vision  and  Chanqe  in  a  Cor 

A.m 

‘I.OOiNPS 

3 

Empowering  Associates  Through  Strategic  ^ 

-1.00 

4  00^  NPS 

A 

Bottom-Line  and  High  Impact  Health  Care  C 

8.00 

"  8.00;  NPS 

5 

Listening  for  Success 

-^.00 

^.00:  NPS 

6 

I  Meeting  Management 

AW 

-^I.OOiNPS 

Figure  1-7.  Database  Table 


The  “Close”  button  takes  the  user  back  to  Officer  Record  form. 


F.  SYSTEM  REPORTS 

EMETRAK  has  ten  pre-formatted  reports.  To  access  EMETRAK  system  reports, 
the  user  selects  the  “Reports”  button  on  the  Officer  Record  form.  This  event  opens  the  ' 
“Select  a  Run”  switchboard  menu  (Figure  1-8). 
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All  Officers  in  Alphabetical  Order 

1 

O 

Officers  Grouped  by  Command 

2 

■ 

List  of  All  Modules  (with  descriptions) 

3 

■1 

Classes  Given  in  the  Last  30  Days 

■ 

Modules  Completed  by  a  Specific  Officer 

5 

1 

List  of  All  Modules  by  Competency 

6 

1 

Officers  and  Completed  Modules  Grouped  ti 

7 

■ 

Profiler 

8 

iJ 

Print  Preview 


'  Print  ; 

_____ 


Figure  1-8.  Reports  Switchboard 


The  “Select  a  Run”  switchboard  allows  the  user  to  select  from  one  of  the  ten  pre¬ 
formatted  reports  in  either  query  view  (tabular  format),  print  preview  mode  or  printed 
format. 


Select  the  desired  report  by  clicking  on  the  report  title  and  clicking  on  either  of 
the  three  action  buttons  (query,  print  preview,  or  print).  Some  reports  require  a  more 
refined  selection  criteria  (e.g.  specific  SSN  or  name)  and  will  prompt  the  user  for  more 
input.  The  user  enters  the  desired  criteria  through  the  use  of  a  dialog  box  similar  to 
Figure  1-9.  Once  the  user  provides  the  criteria  and  presses  enter  the  report  ean  either  be 
viewed  or  printed  depending  on  the  seleetion. 


Of  .  rv 

Fmos  Sitter  for  ell  OMii£»f»  : 

'  '  'j  "  I 


Figure  1-9.  Input  Box 

The  “Close”  button  returns  the  user  to  the  Officer  Record  form. 


G.  VIEWING  OFFICER  COMPETENCIES 


Selecting  the 


Competencies 


button  opens  the  officer’s  Competency  Count 


form  (Figure  I- 10).  The  Competency  Count  form  shows  the  number  of  hours  that  the 
officer  has  completed  grouped  by  EME  competency  category. 
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Figure  I-IO.  Competency  Count  Form 

Close  the  Competency  Count  form  by  double-clicking  on  the  minus  (-)  sign  in  the 
upper  left  comer  of  the  form. 

H.  CLOSING  THE  APPLICATION 


ipirp  I 

I - 2- - i  Clicking  on  the  “Exit”  button  on  the  Officer  Record  form  closes  the 

EMETRAK  application.  However,  before  the  application  completely  closes  down,  the 
user  is  presented  with  a  dialog  box  which  asks  if  you  desire  to  back  up  the  database 
(Figure  I-ll). 


Figure  I-ll.  Exit  Dialog  Box 

Selecting  “Yes”  on  the  Back  Up  or  Exit  dialog  box  starts  the  back  up  procedure. 
The  back  up  procedure  takes  several  minutes  and  requires  that  you  insert  1 .44  MB  floppy 
disks  in  drive  a:  when  prompted.  After  the  the  back  up  procedure  is  completed,  select 
“OK”  in  the  appropriate  message  box  and  the  application  will  close  normally.  If  “No”  is 
selected  in  the  Back  Up  or  Exit  dialog  box,  the  EMETRAK  program  automatically 
closes  out  to  the  Windows  desk  top.  The  alternate  method  of  closing  the  EMETRAK 
application  is  by  selecting  “Exit”  from  the  “File”  pull-down  menu.  This  method  by¬ 
passes  the  back  up  procedure. 
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EXIT  TO  SYSTEM 


APPENDIX  J.  MULTI-USER  SYSTEM  STATE 
TRANSITION  DIAGRAMS 
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Verify  Password  and  Filter  I  Verify  Password  But  No 

forUIC  Filter 
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